world_entities

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

With zero annotations, the description carries the full disclosure burden and excels: it reveals the 200-entry cap with a separately reported true total, explains that distance is HORIZONTAL because the engine's radius test ignores height (with a concrete Chernarus example that proves why a straight-line reading would be misleading), and discloses that players are deliberately excluded, including the safety rationale. This anticipates exactly the behavioral traps an agent would stumble into.

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 dense paragraphs, each earning its place: purpose/contrast, pagination, distance semantics, player exclusion. The core message is front-loaded in the opening line. The Chernarus example is lengthy but necessary to make the horizontal-distance warning concrete and credible; nothing feels padded or repetitive.

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?

Given no annotations and 0% schema coverage, this is a complex tool to document, and the description covers every major trap: what it returns vs world_state, empty-class_name semantics, pagination interpretation, horizontal distance, and player exclusion. An output schema exists, so return-value explanation is rightly omitted. Minor omissions are timeout semantics and an explicit pos format specification, though both are partially inferable from the example.

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 compensate, and it does substantially: the empty-class_name meaning ('lists everything found rather than nothing') is critical and non-obvious, the pagination note directly explains the limit parameter's cap behavior, and the radius/distance discussion clarifies how the radius filter is actually applied. The only gap is timeout, which receives no added meaning, and pos format is conveyed only by example ('7500 0 7500').

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 leads with a precise contrast: 'WHICH objects are nearby, not how many,' then names the sibling it is not ('world_state counts; this one names them'). It states the exact resource, the verb (name/list nearby objects), and the returned fields (class, position, distance, health). An agent can distinguish it from world_state without opening either 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?

It explicitly names the alternative tool and the selection condition: 'world_state(class_name=...) counts; this one names them.' It also gives concrete usage guidance for edge behavior (empty class_name lists everything rather than nothing) and for interpreting pagination (total > count means more results exist). The player-exclusion note additionally frames when this tool is safe to pair with bulk deletes.

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