world_info

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

With no annotations, the description carries full behavioral burden, and it does add real value by enumerating the metadata fields returned (world, data revision, game version, export date, class data revision, size, sea level) even though no output schema exists. It does not say whether the two modes (near vs place) are mutually exclusive or combinable, how many place results come back or whether they are capped, or what happens when no map/session is resolvable. For a read tool with zero annotation coverage, that leaves material gaps.

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 dense semicolon-chained sentence that packs in real information with little filler, which is a virtue. However, the opening clause is grammatically awkward and the two capabilities are not separated structurally, making it harder to parse than a short list of the two functions would 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 4-parameter, read-only tool with a nested object and no output schema, the definition covers the return fields and the two lookup modes adequately. It does not explain interaction between `near` and `place`, result limits, or session resolution, which are the kinds of details an agent would want before calling. Adequate but with clear gaps.

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 only 50%: `near` and `place` have no schema descriptions at all, so the description must carry them — and it does, explaining `near` accepts X/Z plus an optional radius defaulting to 2000 m and `place` is a text match. It also clarifies `map` falls back to the session's map, matching the schema. `session` semantics are only referenced obliquely ("the session's map") and could be clearer.

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 does convey two concrete capabilities: reporting map metadata (world, revisions, size, sea level) and looking up place names. But it never uses a clear verb+resource frame ("Which map data exist" is an awkward interrogative), and it bundles two distinct operations into one sentence without naming them as distinct. It also does not distinguish this from siblings like world_objects, ground_at, or class_info that operate on the same map.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative sibling is named. An agent must infer that this is the place for map metadata and place-name lookup rather than object/terrain queries, but the description never states that. The radius default (2000 m) is a useful hint about intended use but is not usage guidance as such.

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