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

With readOnlyHint=true and openWorldHint=false already declaring a safe, local read, the description earns credit for disclosing return content that no output schema provides: streak target of 67 days, 8-week history window, 'weakest first' ordering, and that advice appears only 'if there is one'. It omits edge behavior such as what happens when task_id refers to a non-habit task.

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?

Front-loaded with a one-line definition, then the two branches in a single dense sentence; no filler sentences. The second sentence is comma-heavy and long, which slightly hurts scanability, but every clause adds distinct return information.

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 read-only tool with no output schema, the description supplies the return contract the schema cannot. It is complete enough to call correctly in either mode. Minor gaps remain around very large habit lists and invalid task_id handling.

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 must carry the parameter, and it does: task_id may be 'any day of the series', not just the start day, and its presence or absence switches the whole result shape. That is meaning beyond the bare string type. It stops short of format specifics (UUID vs id) or error conditions.

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?

It states the exact resource and what is returned in both modes: a habit's planned-vs-done over 4 weeks, streak toward 67 days, 8 weeks of history, verdict and suggestion, and month report; without a task_id, every live habit weakest-first. 'A habit is a repeating task' anchors the resource, making it distinguishable from the generic task tools. An agent knows exactly what this tool yields without opening a schema that has no descriptions anyway.

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?

The two modes are explicitly gated on task_id: 'With task_id (any day of the series)' versus 'Without task_id: every live habit'. This gives clear conditional guidance. It does not, however, say when to reach for get_habit instead of siblings like get_tasks or get_today, so sibling routing is left to inference.

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