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

Beyond the readOnlyHint/destructiveHint annotations, it discloses material behavior an agent could not infer: public/no-auth access, a live X check for uncollected posts, that collection is rate-limited, and that unserved posts signal deletion/protection/withholding. It also pre-empts the most common zero explanation (RULE ZERO) and the copied-post x0 path with its duplicate-check provenance.

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?

Content is largely on-topic, but it is one dense, run-on block with all-caps fragments and stacked parentheticals that hurt scannability. The opening HISTORY/Tailwind-retirement note is important yet front-loads a side topic ahead of the core 'why did this post score' purpose.

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?

There is no output schema, so the description must convey return semantics and it does thoroughly: the weight formulas, per-day placement multipliers, RULE ZERO, the copied check with a link to the duplicated post, and the final seeds. For a single-parameter, complex scoring tool this is complete enough to interpret the response.

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 carries the burden, and it does: post_id is defined as the numeric id extracted from an x.com/…/status/<id> link, which tells the agent exactly what format to pass. No further semantics (e.g., behavior on a malformed or unknown id) are added, keeping it just short of full compensation.

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 lead sentence 'WHY A POST SCORED WHAT IT SCORED — the honest, checkable breakdown for one post' gives a specific verb and resource with clear scope (one post). It distinguishes itself from board_get ('see board_get ... for what pays now'), but never addresses the very similar sibling justify_seeds, so an agent still has to guess which explainer to call.

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 gives concrete invocation context ('Pass post_id (the numeric id from any x.com/…/status/<id> link)') and routes the agent to board_get for current rules, plus notes the date boundary that selects which arithmetic applies. It stops short of an explicit when-not-to-use or a direct contrast with justify_seeds/seeds_recent_posts.

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