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

With no annotations, the description carries the full behavioral burden, and it does useful work by disclosing the scoring rule (only the FIRST correct answer per key per puzzle counts) and the UTC Monday week boundary — non-obvious logic an agent could not get from the schema. It leaves gaps that matter for interpreting output: whether all keys are listed or only a top slice, whether the result is ordered, and what an inactive week returns. These are inference-level gaps for a simple read tool, not contradictions.

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?

Two sentences, both load-bearing: the first defines the payload and its aggregation rule, the second defines the time window. The resource and cadence are front-loaded, and there is no filler, hedging, or restated tool name.

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 one-optional-parameter read tool with no annotations and no output schema, the definition covers what the data means and how weeks are computed, which is the hard part. It omits result ordering and any cap on the number of keys returned, so an agent cannot fully predict the shape of a response — the only remaining gap for a tool this simple.

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 100%, so baseline would be 3, but the description adds meaning the schema does not contain: that weeks are anchored to Monday in UTC, which tells the agent how a mid-week date is bucketed. The schema already covers the YYYY-MM-DD format and the 'any day of the week' default, so the description is not just restating it. It stops short of explaining how the boundary interacts with the default value.

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 first clause names the resource (leaderboard) and its cadence (weekly), and the colon-introduced clause states exactly what is aggregated: points per signing key for the first correct answer to each puzzle. It is specific rather than tautological. It does not explicitly say 'returns/retrieves', and there is no sibling differentiation, but no sibling (answer_submit, probe, puzzle_data, puzzle_get, puzzles_today) overlaps in purpose, so confusion risk is low.

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, when-not-to-use, or alternative-tool guidance; usage is only implied by the tool's name and the fact that it is the sole leaderboard endpoint. The week-boundary and default-week semantics in the schema make invocation predictable, which partly compensates. Nothing misleading, but the agent must infer the trigger condition.

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