inventory

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is domain semantics — and it delivers: `spendable` is defined as carried + storage + Dimensional Depot, machine buffers and crates are explicitly excluded from that sum, and fluid units are stated as m3. These are non-obvious aggregation rules an agent could not infer from structured fields. Return shape is only implied, not stated.

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?

Front-loaded with the two modes, then the aggregation rule, then the unit note, then the per-parameter scoping — a sensible information order with no filler. The telegraphic phrasing ('place and fill', 'shown apart, never added in') is dense but readable. Slightly clipped style costs it the top mark.

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 11 parameters and no output schema, the description does the important work: it sketches what each view returns (per-item totals; per-container with place and fill) and defines the spendable aggregate. Enough to call it correctly for the common cases; the undocumented `save`/`world`/pagination parameters are the residual 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?

Schema coverage is 55%, so the description must compensate, and it does for `item`, `show`, `near`, `container_kind` and `empty` by tying them to views. However `save`, `world`, `limit`, `offset` and especially `radius_m` (clearly coupled to `near`) carry no explanation anywhere, leaving a meaningful gap in a mutation-free but 11-parameter tool.

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?

Opens with a concrete verb-and-resource framing ('What you own') and immediately enumerates the two output modes: per-item totals vs per-container/crate/fluid-buffer listing. An agent can tell this is an ownership/inventory query and not a plan or factory tool. It stops short of naming a sibling (e.g. `crates`) it might be confused with, which keeps it from a 5.

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 states the mode switch (`show=containers`) and then scopes which parameters apply to which view: `item=` narrows either view, while `near=`, `container_kind=` and `empty=` are containers-only. That is real routing guidance an agent can act on. No exclusions or alternative-tool pointers are given, so not a 5.

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