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

Annotations already declare readOnlyHint and non-destructive, so the safety profile is covered. The description adds real behavioral value: the matching rule (activity within a day either side, roughly matching duration), the plain-English reason per session, the rendering format, and the explicit caveat that effort is not judged.

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 the outcome and matching logic, then a compact args section. Slightly longer than strictly necessary, but every sentence conveys operationally useful 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?

An output schema exists so return values need not be described, and the description still explains the card format and the per-session reason field. The matching criteria and the non-judgment of effort complete the picture for an agent deciding whether this answers a progress question.

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 must carry the parameter, and it does: 'weeks' is defined as how many weeks back including the current one, with the 1-12 bound stated. Only the default value (6) is left to the schema, which is acceptable.

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 states a specific verb and resource: it reports which planned sessions were completed, week by week, as a plan card. It clearly differs from get_plan (structure) by focusing on completion/adherence, though it never names get_plan explicitly to reinforce the distinction.

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 implied by the adherence-reporting framing, but there is no explicit when-to-use / when-not guidance and no mention of siblings like get_plan or get_activities that an agent might otherwise choose for similar questions.

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