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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context — that free-form dates are parsed ("Dec 12", "in 3 weeks") and that milestones are spread between a start date and due date — but with no output schema it never describes what a returned milestone looks like (names, dates, sequencing), leaving the result shape opaque.

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?

Three short sentences, front-loaded with the core definition, followed by the date-format caveat and a single illustrative prompt. Nothing is redundant, though the leading "List" wastes the most prominent slot on a misleading verb.

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 5 parameters (3 required), full schema coverage and no output schema, most structured information is present elsewhere. The remaining gaps are material: no clarification of how this differs from `list_assignment_milestones`, and no hint of the return format for a generative planning tool whose output shape is otherwise undocumented.

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 100%, so `title`, `due_date`, `start_date`, `estimated_hours` and `steps` are all documented structurally — baseline 3 applies. The description reinforces the natural-language date handling already stated in the schema, and the example illustrates the interplay of hours and due date, but adds no new meaning about `steps`, `share`, or `start_date`'s default behavior.

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 names a concrete resource (dated milestones splitting an assignment between start and due date) and the example prompt reveals that it *generates* a breakdown rather than retrieving stored data. However, it opens with the verb "List", which makes it easily confused with the sibling `list_assignment_milestones`; no sibling is named or differentiated, so an agent cannot reliably choose between the two from the description alone.

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 example prompt ("Break my 6 hour essay due 2026-11-20 into milestones") implies the intended usage context — planning a large assignment with a due date. There is no explicit statement of when to prefer this over `list_assignment_milestones`, `make_study_plan`, or `spaced_repetition_dates`, and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real behavior beyond them — sessions are split by urgency, a warning is emitted when hours don't fit, and review entries surface as 'Review:' in the plan and calendar. It also discloses the flexible natural-language date parsing ('Dec 12', 'in 3 weeks'), which is non-obvious and not stated in annotations.

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?

Purpose is front-loaded in the first sentence and every subsequent sentence maps to a distinct capability (per-weekday hours, topics, reviews, date parsing). It is somewhat dense and contains awkward phrasing ('Give an exam topics with their own hours'), but no sentence is redundant.

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 7-parameter tool with no output schema, the description covers the important input interplay and sketches the output (dated sessions, urgency ordering, fit warnings, review entries). The remaining gap is sibling disambiguation — with make_study_plan present, the agent still cannot tell from this text which builder to call.

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 genuine semantics: how hours_per_weekday interacts with hours_per_day, that topics-with-hours cause each day to be labeled with a topic, and that reviews require the first-study date. The worked example prompt ties the parameters together in a way the schema cannot.

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 and resource: 'Build a day by day study plan for one or more exams,' which tells an agent exactly what is produced (dated sessions split by urgency). It never distinguishes itself from the close sibling 'make_study_plan' or 'plan_pomodoro_sessions', so in a 12-tool set the agent has no textual basis for choosing between them.

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?

Gives clear invocation context: supply each exam's date plus hours_per_day, or hours_per_weekday for per-weekday scheduling, and optionally topics or reviews. There are no exclusions or named alternatives, so the agent knows when it applies but not when a sibling is the better choice.

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

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

Annotations already cover safety (readOnlyHint) and world-openness, so the description's job is to say what the evaluation actually produces — and it does, listing every reported metric plus the On track/Behind verdict and the assumption set it reuses. It does not mention error handling for malformed dates or what happens to past-due exams, which keeps it out of the top band.

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?

The purpose and output list are front-loaded in a single dense sentence, followed by the two pieces of caller guidance that actually matter (from_date, flexible date formats). The example prompt earns its place by demonstrating the natural-language date input, though it slightly elongates an otherwise tight description.

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 and five parameters, the description correctly spends its words describing the returned metrics and the assumptions behind the verdict. An agent could call this correctly from the description plus schema; only edge behavior (past exam dates, malformed date strings) is left implicit.

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% and every parameter, including the nested topic hours and weekday-hour objects, is already documented in the input schema. The description adds only the consistency constraint that hours_per_day, hours_per_weekday and days_off should match the plan tools, and repeats the plain-text date parsing already stated in the schema — so baseline 3 is right.

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 and resource — checking whether you are on track for each exam — and enumerates the exact outputs (days left, study days left, hours still to study, hours per study day, On track/Behind verdict). That framing cleanly separates it from the plan-creating siblings like make_study_plan and build_study_plan.

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?

Implies its role as the read-only check that runs against a plan, and tells the agent to pass from_date to count from a fixed day. It stops short of an explicit 'use this after make_study_plan, use X instead if you have no plan yet' routing statement, so the agent must infer the ordering from 'the same hours per day ... as the plan tools'.

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

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

The description adds substantial behavioral detail beyond the readOnlyHint and openWorldHint annotations: it returns the whole file, study sessions become free all-day events, exams become busy all-day events unless include_exams is false, and reviews produce extra events. It also explains topic descriptions and date parsing behavior.

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?

The description is front-loaded with the core purpose and is appropriately sized for a complex export tool. It is somewhat long and includes details that could be tightened, but each part contributes to understanding the output.

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?

Given eight parameters, no output schema, and the need to understand a generated file, the description is complete enough. It explains the return value as a whole .ics file and describes the resulting calendar events, which are the key missing structured information.

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. The description still adds useful semantic context for parameters such as include_exams, hours_per_weekday, and reviews by explaining their observable effects on the generated calendar file.

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 gives a specific verb and resource: turning a study plan into an .ics calendar file for import into Google Calendar or Apple Calendar. It also distinguishes itself from build_study_plan by explaining that it builds the same plan but exports it as a calendar file.

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 clear: use it when you need a calendar-importable file, and the example prompt reinforces the scenario. The relation to build_study_plan is mentioned, but it does not explicitly state when to choose this tool versus build_study_plan or other planning siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: default steps, flexible plain-text date parsing, and that a start date defaults to today, though it says nothing about the shape of the returned milestones.

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?

The core capability is front-loaded in the first clause, and the default steps and date-format note follow logically. The example prompt is a useful illustration rather than filler, keeping the description tight overall.

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 should clarify what the milestones look like (names plus computed dates, one per step). It implies this but never states the return shape, leaving a meaningful gap for a tool whose whole purpose is producing a dated list.

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 100%, so every parameter (title, due_date, start_date, estimated_hours, steps) is already documented with formats and defaults. The description only restates the default steps and plain-text date flexibility, adding no syntax the schema doesn't already carry.

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 resource (dated milestones splitting an assignment from start date to due date) and explains the default step breakdown, so the operation is concrete. It does not, however, distinguish this tool from the sibling 'assignment_milestones', and the verb 'List' understates that it generates/computes milestones rather than retrieving stored ones.

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?

An example prompt ('Break my 6 hour essay due 2026-11-20 into milestones') gives a clear usage context and the description notes that steps default to research/outline/draft/revise/proofread. It lacks explicit when-not conditions or a named alternative among the many sibling planning tools.

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

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

The annotations already establish read-only and open-world behavior, and the description adds useful context: reviews expand from the first study date and dates on or after the exam are skipped. It also clarifies that dates may be plain text, which is relevant to the openWorldHint annotation.

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?

The description is short and front-loaded, immediately stating what the tool produces before giving the alternative and date-format guidance. The example prompt is compact and helps clarify intended usage without wasting space.

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 usefully explains the returned schedule as every review date at expanding intervals with post-exam dates skipped. Combined with thorough parameter descriptions and read-only annotations, it is nearly complete, though the exact return shape is not specified.

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 schema already documents topic, exam_date, intervals_days, and first_study_date. The description reinforces exam skipping and date formats but adds little parameter meaning beyond what the schema provides, making 3 the appropriate baseline.

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: making a spaced repetition schedule for a topic, with expanding review intervals and exam-date skipping. It also explicitly distinguishes the tool from next_review_dates, which covers only the next review date.

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 gives a clear usage condition by saying to use next_review_dates when only the next review date is wanted, implying this tool is for the full schedule. It does not address all sibling tools such as spaced_repetition_dates or make_study_plan, but the main alternative is covered.

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

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

Beyond the readOnly/openWorld annotations, the description discloses non-obvious behavior: hours are shared across exams by urgency, study stops the day before each exam, insufficient time produces a warning, and reviews generate Review entries in the plan and calendar. It does not describe the returned plan structure in detail, but it adds substantial behavioral context.

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?

The description is front-loaded with the core behavior and then moves through advanced options before ending with a concrete example prompt. It is dense but mostly purposeful; a few clauses are run-on, but there is little wasted text.

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 seven-parameter planning tool with no output schema, the description covers the main scheduling logic, warning behavior, and review entries. It leaves some gaps around the exact returned plan format and the roles of days_off and intervals_days, but the core behavior an agent needs to invoke it is present.

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. The description nevertheless adds useful semantics beyond the schema: why hours_per_weekday matters, how topics with own hours affect the daily topic assignment, and how reviews use the first study date. It does not cover days_off or intervals_days explicitly, keeping it from a 5.

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 ('Build a day by day study plan for one or more exams') and explains the core output concept. It does not distinguish itself from the close sibling 'build_study_plan', leaving ambiguity about which plan-generation tool to choose.

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 example prompt and by mentions of topics, reviews, and weekday hours, but there is no explicit 'use this when' guidance or comparison with alternatives such as build_study_plan, export_study_plan_ics, or make_spaced_repetition_schedule.

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

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

Beyond the readOnly/openWorld annotations, the description explains the selection logic: the first review that is not on or after the exam and has not passed, counting from the first study date. It also discloses that dates can be accepted as plain text, which is useful behavioral context for invocation.

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?

The description is front-loaded with the core purpose and selection rule, followed by the key alternative and a concrete example. Each sentence contributes useful information without unnecessary repetition.

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, open-world scheduling query with a fully documented schema, the description is largely complete. It does not specify what happens when no future review exists, but that is a minor gap for this tool.

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 100%, so the input schema already documents all five parameters thoroughly. The description reinforces the relationship between exam_date, from_date, and first_study_date, but it does not add meaningfully new details about intervals_days beyond what the schema provides.

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 gives the next review date for one topic, not the whole schedule. It also explicitly contrasts itself with make_spaced_repetition_schedule, making the tool easy to distinguish from a sibling.

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 clearly says to use make_spaced_repetition_schedule when every review date is wanted, which implies this tool is for a single next date. The guidance is strong but does not address the other similarly named sibling spaced_repetition_dates, leaving a small ambiguity.

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

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

The description adds useful behavioral detail beyond the annotations: work blocks are separated by short breaks, a long break follows a set number of sessions, and start_time changes output from minute offsets to clock times. It does not describe every return detail, but with readOnlyHint=true and openWorldHint=true already indicating a safe read-only planning operation, the added context is meaningful.

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?

The description is front-loaded with the core purpose and progresses logically to start_time behavior and an example. It is efficient overall, though the example prompt is somewhat redundant given the preceding explanation. No sentence is seriously wasteful, but the example could be omitted without losing much.

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 6-parameter tool with only one required parameter, full schema coverage, and no output schema, the description covers the main behavior and the key optional start_time formatting choice. It does not explain edge cases like total_minutes limits, but the schema handles those. An agent has enough context to invoke the tool correctly.

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 100%, so the input schema already documents all six parameters, including defaults and the start_time behavior. The description reinforces start_time with an example and explains the pomodoro structure, but it adds little parameter-specific meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 uses a specific verb and resource: plan pomodoro sessions for a total amount of study time. It clearly explains the structure of work blocks, short breaks, and long breaks. It does not, however, differentiate this tool from the very similar sibling pomodoro_plan, which leaves ambiguity for an agent choosing between them.

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 gives clear usage context: provide total study time, optionally give start_time like 09:00, and receive clock times per block. The example prompt reinforces the intended invocation. It does not say when to prefer this over pomodoro_plan or make_study_plan, so it lacks explicit alternatives or exclusions.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description usefully indicates the return shape (clock times per block when start_time is given, otherwise minutes from the start), which matters because there is no output schema, but it says nothing about edge cases such as totals that don't divide evenly into work blocks.

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 tight sentences front-load the purpose and the start_time behavior, followed by a short example prompt. The example is slightly redundant with the preceding sentence but is not wasteful.

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 six fully documented parameters and no output schema, the description does give the return concept needed to interpret results. However, it leaves the biggest ambiguity for an agent – how this differs from the sibling plan_pomodoro_sessions – entirely unaddressed.

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 100%, and the description mostly restates what the schema already documents, including the 09:00 example for start_time. Baseline 3 is appropriate since the schema carries the parameter burden.

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 (plan) and resource (pomodoro sessions) and summarizes the output shape: a work and break schedule with a long break after a set number of sessions. It is clear on its own, but it does nothing to distinguish itself from the near-identical sibling 'plan_pomodoro_sessions'.

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 only implied through an example prompt ('Plan 3 hours of studying as pomodoro blocks with breaks'). There is no guidance on when to prefer this over plan_pomodoro_sessions or when a pomodoro plan is the wrong choice versus a full study plan.

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

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral detail beyond that: dates on or after the exam are 'marked to skip' rather than silently dropped, and dates accept natural-language input. It does not describe the shape of the returned list, which is a minor gap given no output schema.

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 core action and scope in the first clause, followed by the exam-cutoff behavior and the input flexibility, then a concrete example prompt. The mid-sentence 'so you revisit it just before you would forget it' is explanatory filler that could be cut without loss.

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 computation with full schema coverage and annotations, the description covers purpose, cutoff behavior, and accepted input formats adequately. The main omission is any hint of the return value (a list of dated entries with skip markers), which matters somewhat since there is no output schema.

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 100%, so all four parameters are already documented, including the flexible date formats and the exam cutoff rule. The description largely restates that ('Dates can be plain text, like Dec 12 or in 3 weeks'; 'Dates on or after the exam are marked to skip') without adding format or default semantics the schema lacks, so baseline 3 applies.

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 and resource — 'List spaced repetition review dates for a topic at expanding intervals' — so an agent immediately knows it returns a computed date list rather than mutating anything. It does not, however, distinguish itself from close siblings like next_review_dates or make_spaced_repetition_schedule, which remain plausible alternatives on name alone.

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 example prompt ('When should I review what I learned today for my exam on 2026-11-30?') gives concrete context for when to reach for this tool. But there is no explicit when-not guidance and no routing against the several overlapping siblings, so the agent must infer the boundary itself.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds what is actually returned (per-day sessions, topics when exams have topics, due and late reviews) and that dates may be plain text. It doesn't discuss failure modes for ambiguous date phrases, but for a read-only query tool the added behavioral context is solid.

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?

Purpose and scope are front-loaded in the first clause, and the worked example prompt is genuinely useful for a natural-language-heavy input. There is minor redundancy — plain-text date formats appear in the description and again in every date property — but nothing is wasted at the sentence level.

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 8 all-optional parameters and no output schema, the description carries the return-value burden and does so (sessions, topics, due/late reviews) while noting the date default. It leaves days_off, intervals_days, and start_date entirely to the schema, which is acceptable given 100% schema coverage but leaves the plan-horizon behavior unstated.

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 non-obvious semantics: exams/hours should mirror build_study_plan inputs (including hours_per_weekday), and reviews pair a topic with the day it was first studied. That cross-tool consistency guidance is value the schema cannot convey.

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 and resource with explicit scope: the study sessions the plan gives for one day, each session's topic, plus spaced repetition reviews that are due or late. It names the sibling build_study_plan as the source of the same exams/hours, so an agent can tell how this differs from the full-plan tool.

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?

Gives concrete invocation guidance: pass the same exams and hours as build_study_plan, including hours_per_weekday, plus reviewed topics with their first-study day; omitting date means today. It stops short of explicit exclusions (e.g., 'for the whole schedule use make_study_plan instead'), so the when-not is only implied by the one-day framing.

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