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

With no annotations, the description carries the full burden and does well: it discloses that located places carry cross-checked lat/lon, disputed sites return named candidates rather than a single coordinate, and unlocatable places are null-coordinate blanks. This is unusually rich output-behavior disclosure, though it says nothing about read-only guarantees or result sizing.

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 resource and its coordinate model, and the final sentence delivers the invocation rule. Some flourish ('honestly held,' 'planting one flag') is decorative, and the '[WORD · internal]' prefix is opaque, but the length earns its place by encoding real behavioral distinctions.

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 single optional-parameter read tool with no output schema or annotations, the description supplies the result-shape detail an agent needs (coordinates present/absent, disputed candidates, counts). The remaining gaps—auth requirements and pagination/result size—are minor for this tool class.

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% and the single parameter is undocumented in the schema, but the description compensates precisely: passing name yields one place, omitting it yields all places with by_status counts. That fully specifies the filter semantics and the empty-parameter branch.

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 makes clear this is an atlas returning biblical places with coordinates, and even disaggregates three categories of results. It states a specific resource and data model, but never names or contrasts with geographic siblings like locate or lookup, so an agent cannot distinguish it from those without opening schemas.

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?

'Pass name for one place; else all places with by_status counts' gives clear input-driven behavior, which is effectively usage guidance for invoking it. However, there is no statement of when to prefer this over alternatives such as locate or search, and no exclusions, so routing is left to inference.

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