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

Annotations already cover the safety profile (readOnlyHint, destructiveHint, openWorldHint), so 'Read-only' is redundant, but the description adds genuine value beyond them: it discloses that completion logs are included, that streaks are computed as consecutive completed periods, and that cadence affects streak calculation. It does not cover ordering or default behavior when 'limit' is applied, which keeps it from a 5.

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 compact sentences front-load the core behavior and return content, then the optional filter. The standalone 'Read-only.' sentence repeats what readOnlyHint already declares and is the one item that does not earn its place.

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?

With no output schema, the description wisely describes what each returned habit contains, including streak semantics, so an agent knows what to expect. Annotations cover safety. The remaining gap is 'limit' behavior — ordering and default — which matters for a list tool capping at 100.

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%, so the description carries the full burden. It clarifies the 'active' boolean ('optionally include only active habits') but says nothing about 'limit' — not its default, its ordering basis, or which habits are dropped at the cap of 100. Half the parameters are effectively explained.

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?

States a specific verb ('List') and resource ('the caller's habits from their active workspace') and further pins down what comes back (recent completion logs, current_streak, longest_streak). The scope is unambiguous and clearly distinct from the ERP/CRM/HR list siblings by resource alone. It stops short of a 5 only because it never explicitly contrasts itself with any alternative.

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 when-to-use or when-not-to-use guidance, no prerequisites, and no named alternative. 'Optionally include only active habits' describes a parameter effect rather than a usage decision. The agent must infer the invocation context entirely from the tool name.

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