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

With readOnlyHint/destructiveHint already covering safety, the description contributes real extra context: install counts are only recorded from 3 installs upward and a missing count means 'not counted, not zero', and GitHub facts carry a refresh timestamp so staleness is disclosed. These data-provenance caveats are exactly the kind of behavior an agent cannot get from the annotations.

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?

The resource is named first, then the ranking modes, then the per-project payload and caveats, so the structure is front-loaded and scannable. The sentences are dense but each carries distinct information (ranking criteria, fields shown, install-count rule, refresh timestamps) rather than filler.

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-field explanation is optional, and the description still previews the projected fields (repo, stars, latest release, last commit, .toc interface number, Everloot installs). Combined with read-only annotations and the board semantics, an agent has what it needs to call this correctly; only explicit when-to-use guidance is absent.

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?

The board enum values are listed in the schema, but the description supplies their meaning (installed = most installed, rising, active = most active, release = freshest release, maintained = best maintained), which the bare enum labels do not convey. 'limit' is undocumented in prose, but the ranking descriptions plus the install-counting semantics add genuine value beyond the 67%-covered schema.

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 names a specific resource (community-registry Forever addons and open-source projects) and scopes it to a ranked board, so an agent knows this returns ecosystem projects rather than game entities. It lacks an explicit verb like 'list', but the content and scope are unambiguous and clearly distinct from the wiki/entity siblings (item_page, npc_page, search_knowledge).

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?

Usage is only implied: the enumerated board modes (most installed, rising, most active, freshest release, best maintained) hint at browse/discovery scenarios, but the description never states when to pick this over another tool or what conditions would exclude it. Since no sibling covers the same addon-registry data, the omission is tolerable but still leaves the agent to infer intent.

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