Reschedule missed days

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the actual computation: hours_done are subtracted from the exam, topics absorb the deduction proportionally, and remaining hours are re-spread from start_date using the same capacity rules as the plan tools. It also states the return shape (hours done, hours left, repaired plan), consistent with a read-only tool that returns rather than persists a plan.

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 purpose, then mechanics, then a worked example — a sensible ordering with little waste. The natural-language date explanation partly duplicates the schema's own date description, costing a bit of tightness.

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 5-parameter tool with no output schema, the description covers purpose, computation, capacity rules, and return contents. There is no output schema to defer to, and the description fills that gap by describing what the response contains.

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 the baseline is 3, but the description adds real semantics: it explains how hours_done interacts with hours_needed and topics, and that hours_per_day/hours_per_weekday/days_off behave identically to the plan tools. It doesn't address edge cases like hours_done exceeding hours_needed.

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 opening sentence names a specific verb and resource — 'Rebuild a study plan after missed study days' — and the scope (recover from missed days) clearly separates it from siblings like make_study_plan or build_study_plan. An agent can choose it without opening the schema.

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 establishes the trigger condition (missed study days, with hours already completed) and reinforces it with a concrete example prompt. It never names an alternative tool for the fresh-plan case, so routing to make_study_plan versus this tool is left implicit.

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