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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add context — and it does: it discloses the data source ('Reads Everloot's current authorized public corpus when connected') and error behavior ('Missing or unavailable data is reported explicitly'). However, the surrounding framing ('One Forever NPC', '3 installs agreeing', 'No copied spawn list') is cryptic and does not clarify what the returned page contains.

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 short and has no filler sentences, but the opening is not front-loaded with the core action; the most informative clause ('Reads ... public corpus') arrives after opaque domain jargon. Sentences earn partial credit but the ordering buries the point.

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?

An output schema exists, so return values need not be described, and annotations cover safety. The remaining burden — what the tool does and when to invoke it versus the many sibling page/entity tools — is not addressed, leaving an agent under-informed for a tool in a crowded namespace.

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?

With a single parameter at 100% schema description coverage, the schema already documents npcId as 'NPC id' with type and bounds. The description adds no format, range, or resolution guidance beyond that, so the baseline 3 is appropriate.

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 never states the action or resource plainly — it opens with 'One Forever NPC: agreed name and map pins' and dwells on agreement mechanics ('3 installs agreeing') rather than saying it retrieves an NPC page by id. Siblings like item_page, object_page, and vendor_page establish the pattern, but this text does not clearly differentiate or name what npc_page returns. A reader cannot confidently restate the tool's job.

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?

There is no explicit when-to-use guidance and no mention of alternatives such as get_entity, get_by_name, or search for resolving an NPC. The only implicit signal is the 'npcId' requirement, which the schema already conveys. Nothing tells an agent which sibling to pick when resolving an NPC.

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