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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered elsewhere. The description adds genuine context by noting that dates may be plain text ('Dec 12', 'in 3 weeks'), which tells the agent fuzzy input is tolerated. It does not explain what the returned milestones look like (dates plus names?) or how hours are distributed across steps.

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: purpose, date-format note, and a worked example. Nothing is padded, and the key idea (splitting an assignment between start and due date) is front-loaded. The only cost is that leading verb 'List', which misdirects slightly.

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 signal the return shape, but it only implies a dated list of steps. For a generation tool with 3 required inputs and a default step set hidden in the schema, readers must go to the schema to learn what output to expect. The missing distinction from 'list_assignment_milestones' is the biggest gap.

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 is already documented in the schema, including the plain-text date formats the description repeats. The description adds no new meaning beyond the schema, so the baseline of 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?

The description says it will 'List dated milestones that split a big assignment into steps between a start date and the due date', which conveys the resource and the start-to-due span. But 'List' implies retrieval of existing data, when the required parameters (title, due_date, estimated_hours) show this tool actually generates a milestone breakdown. The sibling tool 'list_assignment_milestones' makes this ambiguity worse, and the description never resolves it.

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') gives a concrete use context, which is better than nothing. However, there is no explicit when-not guidance and no mention of the near-identical sibling 'list_assignment_milestones' or how this tool relates to 'build_study_plan'/'make_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?

Annotations already declare readOnly=true, idempotent=true, destructive=false and closed-world, and the description adds genuinely new behavior: sessions are split by urgency, the plan emits a warning when available hours do not fit, and reviews appear as 'Review:' entries in the plan and calendar. Remaining gaps (format of the returned plan, what the warning looks like) are covered by the output schema, so the bar is met without exceeding it.

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 main inputs are front-loaded, and the example prompt earns its place, but the middle sentences are dense and grammatically rough ('Give an exam topics with their own hours and the plan names the topic of each day'), and the free-text date capability is restated three times across the description. The content is relevant but the phrasing costs comprehension.

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 planning tool with a full schema, an output schema, and rich annotations, the description covers the main input modes, the fallback/precedence rules for hours, date flexibility, and the two notable behaviors (urgency splitting and the hours-don't-fit warning). What is missing is only routing against the near-duplicate sibling make_study_plan, which is an adjacent concern rather than a call-correctness gap.

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, and the description does add real semantics beyond the schema: weekday hours you leave out fall back to hours_per_day, a weekday with 0 is a day off, days in days_off are always excluded, and dates accept free text like Dec 12 or in 3 weeks. It never mentions start_date, intervals_days, or the default hours_per_day of 3 explicitly, so it adds meaning without fully compensating beyond the already-complete schema.

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?

Opens with a specific verb and resource: 'Build a day by day study plan for one or more exams', and the rest of the description clarifies the outputs (dated sessions split by urgency, topic labels, Review: entries). It never names or distinguishes itself from the very similar sibling make_study_plan, so the agent gets a clear purpose but no sibling differentiation.

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 shown rather than explained: it tells you which inputs to supply for each mode (hours_per_weekday for per-weekday hours, topics with hours for topic labeling, reviews with first_study_date for review entries) and closes with an example prompt. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as make_study_plan, reschedule_missed_days, or spaced_repetition_dates, so the agent must infer which tool applies.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it explains the computation basis (shared assumptions with the plan tools) and lists exactly what each per-exam result contains, including the plain On track/Behind verdict.

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 is front-loaded in the first sentence, followed by the output inventory and then the parameter tip. The trailing example prompt is somewhat redundant with the schema's date-format notes but useful for illustrating the intended query, and overall 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?

With an output schema present, the description need not explain return shapes in detail, and annotations cover safety. Combined with 100% parameter coverage, the definition is complete enough to invoke correctly; the only soft spot is the absence of explicit routing to sibling tools for plan creation or rescheduling.

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 five parameters are already documented in the schema, including date formats, defaults, hours_per_weekday fallback logic and the days_off interaction. The description adds the from_date default-to-today nuance and reinforces flexible date parsing, but does not explain the returned-hours default of 10 or other semantics beyond what the schema states, 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 — 'check whether you are on track for each exam' – and enumerates the verdict metrics (days left, study days left, hours still to study, hours per study day, On track/Behind). It also distinguishes itself from the planning siblings by saying it reuses the 'same hours per day, hours per weekday and days off as the plan tools', though it never names a specific sibling such as make_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?

Gives clear usage context: it is the status-checking companion to the plan tools, and it tells the agent to supply from_date when counting from a fixed day rather than today. The example prompt demonstrates the intended question shape. It stops short of explicit when-not guidance or naming which alternative to use for creating or rescheduling a 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?

With annotations already covering read-only, idempotent and non-destructive, the description nonetheless adds substantial new behavior: the whole file is returned and should be saved as plan.ics, sessions become free all-day events with topic names in the description, exams become busy all-day events unless include_exams is false, and reviews generate 'Review:' events. That is exactly the complementary context annotations cannot provide.

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 content is front-loaded with purpose and output handling, and each sentence carries information about event semantics or invocation. It is somewhat dense and long, with a little overlap against the schema, but nothing is padding.

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?

There is no output schema, and the description compensates by explaining what comes back (the whole file), what to do with it, and how the calendar entries are shaped. For an 8-parameter export tool, an agent has everything needed to call it and interpret the result.

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 schema already documents every parameter, including plain-text date formats and hours_per_weekday fallback rules. The description adds only the parity note ('same hours_per_weekday') and the include_exams event semantics, which the schema mostly covers too. 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 opening sentence gives a specific verb and resource: 'Turn a study plan into an .ics calendar file', and names the concrete consumer (Google Calendar or Apple Calendar). It also distinguishes itself from build_study_plan by output form (same plan, but returned as a file), so an agent can pick it out of a crowded sibling list.

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 context is clear: it is the export path when the user wants a calendar file, and it explicitly mirrors build_study_plan's planning behavior. A closing example prompt reinforces the when. It stops short of an explicit exclusion ('use build_study_plan if you only want the schedule text'), which keeps it from a 5.

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 readOnly, idempotent, non-destructive and closed-world, and the description is consistent with them. Beyond that, it usefully discloses two behavioral traits: that steps default to a fixed five-stage set, and that dates accept lenient plain-text input ('Dec 12', 'in 3 weeks'). It does not say what the returned milestones look like or how shares map to durations, but with annotations and schema covering much ground this is a minor gap.

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 operation before the softer date-format and example details. The quoted example prompt earns its place by illustrating input shape. Slight redundancy with the schema's date-format text keeps it from a 5.

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?

Five parameters with three required, no output schema, and read-only annotations — the burden on the description is modest and it is met. Purpose, defaults, and date flexibility are all covered, and no safety or permission information is needed for a pure computation 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 every parameter including the nested step 'share' is already documented with format examples and defaults. The description restates the default step list and the date leniency without adding syntax or constraints the schema lacks. Baseline 3 applies where the schema does the heavy lifting.

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 dated milestones that split an assignment between a start date and due date, with a named default step set. An agent understands the operation immediately. It stops short of distinguishing itself from the near-identical sibling 'assignment_milestones', leaving ambiguity about which to pick.

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') implicitly conveys a valid use case and triggers. But there is no explicit when-to-use / when-not-to-use statement, no prerequisite conditions, and no routing to alternatives such as assignment_milestones or make_study_plan, which are the obvious competing choices.

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 read-only, non-destructive annotations, it explains that reviews are calculated from the first study date and that entries on or after the exam are marked to skip rather than silently omitted. It does not describe the returned schedule's structure or how relative dates are resolved, so it is informative but not exhaustive.

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 front-loads the function and cutoff behavior, then presents the alternative, input flexibility, and a short example in a logical order. Its four compact sentences each contribute selection or invocation guidance without substantial 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?

Together with the fully described schema and safety annotations, this is enough for an agent to construct a normal call and understand skip behavior. Because there is no output schema, the absence of a return-shape description is a small gap, and the near-duplicate sibling spaced_repetition_dates is not differentiated.

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 and the schema already documents defaults, interval customization, and accepted date formats. The description reinforces date flexibility and first-study/exam semantics with an example, but adds little parameter information beyond the schema.

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 identifies the action and resource—making a full review schedule for a topic—and explains the interval origin and exam cutoff. Naming next_review_dates as the next-date-only alternative also distinguishes it from a close 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 gives an explicit routing rule: use next_review_dates when only the next review date is wanted, making this tool appropriate for the full schedule. The example prompt supplies a concrete use case involving first study date and exam date.

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 establish that this is a safe, idempotent, non-destructive read, so the description is not burdened with safety disclosure. It does add real behavioral context: daily hours are shared across exams by urgency, study stops the day before each exam, and the result warns when time is insufficient. That is exactly the kind of non-obvious scheduling rule an agent needs before calling.

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 purpose is front-loaded, but the rest is one long run-on chain of clauses joined by commas and 'and', which makes conditional rules harder to parse than they need to be. Dense rather than wasteful, but structure could be improved with clearer separation of the conditional hints.

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 no explanation. Combined with annotations, the description covers the scheduling rules, the warning behavior, the flexible date format, and the topic/review augmentation, leaving few gaps. The only missing piece is disambiguation from build_study_plan.

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 goes beyond the schema by explaining the relationship between parameters: hours_per_weekday overrides hours_per_day for the given weekdays, and topics with their own hours produce a per-day topic assignment. It also restates that dates accept plain text such as 'Dec 12' or 'in 3 weeks', reinforcing a flexible-format contract.

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 opens with a specific verb and resource: 'Build a day by day study plan for one or more exams.' That is unambiguous. However, a sibling named build_study_plan exists and the description never says how this tool differs from it, so an agent cannot route between the two from the text 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?

It gives conditional guidance for optional features ('Set hours_per_weekday when your weekdays and your weekend differ', 'give an exam topics with their own hours'), which is useful. But it never states when to call this versus build_study_plan or the other scheduling siblings, which is the main routing risk here.

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, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description contributes behaviour beyond that: that a single date is returned rather than a schedule, and that already-passed reviews are factored in. That counting note is useful but phrased in a way that sits awkwardly against the 'has not passed yet' clause.

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 intent is front-loaded in the first clause, but the body repeats itself: the 'single date instead of the whole schedule' framing is restated by the make_spaced_repetition_schedule sentence, and the passed-reviews note partially conflicts with the earlier rule. A tighter, unambiguous one-line definition of the selection rule would be better.

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 correctly states what comes back (a single date) and the accepted date formats. For a read-only, closed-world calculation tool with a single required parameter, that covers what an agent needs to invoke it correctly; only the precise selection rule remains fuzzier than ideal.

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 each parameter is already documented individually. The description still earns credit by explaining how the parameters interact (exam boundary, counting origin from first_study_date, and the interval sequence), which no single schema field expresses. It repeats the accepted date formats that the schema already states, which is minor redundancy rather than added meaning.

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 specific operation (return the next review date for one topic) and explicitly contrasts it with the whole-schedule tool, so a reader can distinguish it from siblings. However, the defining sentence ('the first review that is not on or after the exam and has not passed yet') is a convoluted double negative that obscures the exact rule being applied.

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 an explicit alternative routing rule: 'Use make_spaced_repetition_schedule when you want every review date,' which tells the agent when to pick the sibling instead. It also supplies a concrete example prompt anchoring the typical use case. It does not address other plausible siblings (e.g., what_to_study_today), but the main fork 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?

Annotations already declare this is a read-only, idempotent, closed-world computation, so safety is covered. The description adds useful behavioral detail about the shape of the generated plan (short breaks between blocks, a long break after a set number of sessions) and how start_time changes the output format, but says nothing about edge cases such as requesting fewer minutes than one work block.

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 purpose, then the output shape, then the start_time modifier and an example. Very little waste; the example sentence earns its place as a selection cue, though it partly duplicates the first sentence.

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 pure computation with no output schema, fully documented parameters, and read-only annotations, the description covers what the tool produces and how start_time affects it. The main missing element is disambiguation from the near-identical sibling 'pomodoro_plan'.

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%, including start_time's two modes, so the schema already does the semantic work and baseline 3 applies. The description reinforces start_time's format and effect but adds nothing about work_minutes, short_break_minutes, long_break_minutes, or sessions_before_long_break beyond the defaults and cadence the schema documents.

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 (plan pomodoro sessions for a total amount of study time) and outlines the resulting structure: work blocks separated by short breaks with a long break every N sessions. However, it never distinguishes itself from the sibling 'pomodoro_plan', which appears to be the same capability, so an agent cannot confidently pick between them 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?

Gives a concrete usage example ('Plan 3 hours of studying as pomodoro blocks with breaks') and an implied condition for supplying start_time (to get clock times). It offers no when-not guidance and no routing versus pomodoro_plan or the other study-planning siblings, so the selection criteria remain inferred.

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 this as a read-only, idempotent, closed-world computation, so safety disclosure is largely covered. The description adds one genuinely useful behavioral fact about output shape: with start_time you get clock times, without it the blocks are listed as minute offsets. It says nothing about defaults being applied, rounding or truncation of total_minutes into whole sessions, or what happens when parameters conflict.

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 with the core capability front-loaded, followed by the one non-obvious input hint and an example prompt. No filler, though the example prompt adds little beyond the preceding sentence.

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 six-parameter, fully documented, read-only planning tool with no output schema, the definition covers purpose, the key optional input, and rough output form. It is nearly complete; the missing pieces are default behavior and result granularity when total_minutes does not divide evenly, plus disambiguation from the duplicate-looking sibling.

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 six parameters are already documented with types, defaults, and bounds; that sets the baseline at 3. The description only restates start_time and the long-break-after-N-sessions concept in prose, adding no constraint or interaction semantics (e.g. how work_minutes and total_minutes interact, or that only total_minutes is required).

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 ('Plan pomodoro sessions') and enumerates the core mechanics: work blocks, breaks, total study time, and a long break after N sessions. It is clear what the tool produces, but it never distinguishes itself from the near-identical sibling 'plan_pomodoro_sessions', leaving the agent to guess which one to call.

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 one concrete usage cue ('Give start_time ... to get clock times for each block') plus a sample prompt, which implies when the tool is appropriate. There is no guidance about when not to use it, no prerequisites, and no routing to alternatives such as plan_pomodoro_sessions, build_study_plan, or make_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 read-only and idempotent annotations, the description explains the core transformation: hours_done are deducted from exams, topic hours are reduced proportionally, and remaining hours are spread from start_date. It also describes the returned hours done, hours left, and repaired 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?

The description is front-loaded with the purpose and algorithm, and most sentences add relevant behavior. Some date-format explanation duplicates the schema, but the example prompt usefully illustrates the intended input.

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 tool with rich schema coverage, annotations, and an output schema, the description covers the scenario, the redistribution logic, topic handling, and the shape of the result. An agent has enough information to invoke it 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 coverage is 100%, so the schema already documents the parameters. The description still adds meaning by clarifying how hours_done affects exams and topics and by stating that planning parameters behave like the plan tools.

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: rebuild a study plan after missed study days. It clearly distinguishes this from initial planning by explaining that completed hours are removed and remaining hours are redistributed.

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 missed-days scenario and example prompt make the intended use clear. It references the same hours parameters as the plan tools but does not explicitly name which sibling to use for non-missed-day planning.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description still adds real behavioral context beyond them — that the review sequence expands and that dates on or after the exam are flagged to skip. What remains undisclosed is the concrete shape of the result (whether skipped dates are omitted or annotated, and the output format), which matters since no output schema exists.

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 purpose and the exam cutoff rule are front-loaded in the first two sentences, with the date-format note and example prompt appended as supporting detail. Slight redundancy with the schema's own prose on plain-text dates keeps it from a 5.

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 four-parameter, read-only, closed-world calculation tool with full schema coverage and no output schema, the description supplies the purpose, the interval concept, the exam cutoff, and the accepted date formats. Nothing essential for a correct call appears to be missing.

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 baseline is 3 — the schema already documents topic, exam_date, intervals_days, and first_study_date, including the plain-text date forms. The description repeats the flexible-date parsing and semi-restates the exam cutoff rather than adding new semantics, though the phrase "expanding intervals" does hint at how intervals_days is interpreted.

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 pairs a specific verb ("List") with a specific resource ("spaced repetition review dates for a topic") and explains the expanding-interval logic, so an agent knows exactly what comes back. It does not, however, distinguish itself from the sibling next_review_dates, which reads like an overlapping capability.

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: the embedded example prompt ("When should I review what I learned today for my exam on 2026-11-30?") shows the intended scenario without stating when to prefer this over next_review_dates, make_spaced_repetition_schedule, or reschedule_missed_days. No exclusions or prerequisites are given.

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 disclose that this is a read-only, idempotent, non-destructive, closed-world call, so the safety profile needs no further work. The description adds the useful detail that one call returns both sessions and due-or-late reviews, and that omitted dates default to today. It does not describe anything beyond what the output schema can convey, so a middle score is right.

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 key behavior is front-loaded in the first sentence, which is good. The closing quoted example prompt is long and restates date formats and defaults that already appear in the schema, so the description is longer than it needs to be. Some trimming would sharpen it without losing 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?

Eight parameters carry no required arguments, the annotations are rich, and an output schema exists, so most of the burden is already lifted. The description still covers the defaults, the flexibility for plain-text dates, and how the inputs should match build_study_plan. That is enough for an agent to call it correctly on a first try.

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 even without parameter prose. The description adds real meaning on top of that: exams and hours_per_weekday should mirror the values used in build_study_plan, and each review should be paired with the day the topic was first studied. Those relationships between parameters are not encoded anywhere in the schema.

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 returns the study sessions planned for one day, each with its topic, plus spaced-repetition reviews that are due or late. That is enough for an agent to tell it apart from make_study_plan or next_review_dates. It stops short of a 5 because the boundary with build_study_plan, which it names as a related tool, is implied rather than stated.

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: call this to answer 'what do I study today' for a single day, and pass the same exams and hours you would give build_study_plan so the two tools agree. The 'leave date out and it uses today' rule and the example prompt make the intended invocation obvious. No explicit exclusions are given, such as when to use spaced_repetition_dates or next_review_dates instead, which keeps it below 5.

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