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

Annotations already declare readOnlyHint=false and openWorldHint=false, so the write-local scope is known. The description adds real behavior beyond that: each class becomes one weekly recurring event with holidays and reading weeks removed, and 'the tool checks the file before returning it.' What it omits is what happens when output_path is not supplied (file content returned vs. nothing), which is the key behavioral ambiguity for a caller.

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, then inputs, then behavior, then an example. The middle sentence is a long run-on enumeration of inputs, but each element maps to a distinct parameter and nothing is redundant with the surrounding sentences.

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, return values need no explanation, and the description covers inputs, defaults, recurrence expansion, holiday exclusion, and validation. The only meaningful gap is the no-output_path case. Comfortable for a 5-parameter optional-only 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 schema already documents every parameter, nested item field, formats, and defaults. The description's parameter enumeration mirrors the schema rather than adding new semantics. 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?

Opens with a precise verb and resource: 'Build a valid .ics calendar file from dated events and recurring classes, with reminders.' The input enumeration makes it clear this is the construction step, not extraction or merging. It never names the siblings (extract_schedule_events, expand_recurring_classes, merge_calendars), so the differentiation is inferred 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?

The concrete example prompt ('Make an .ics file for my course with a reminder one day before each assignment') anchors when this tool applies, and the defaults documented for reminders_minutes and calendar_name give calling context. There is no explicit when-not guidance or routing to the sibling tools, so it stops short of 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral detail beyond that: it returns every meeting date plus skipped dates with reasons, and terminates with a next-step hint. It does not mention output ordering/format limits, keeping it short of a 5.

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, then inputs, then return behavior, then the example prompt. The enumerated input list partly duplicates the schema, but the example prompt earns its place by showing the intended invocation shape. Slightly verbose but well-ordered.

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 10-parameter tool with an output schema, the description covers purpose, input shapes, return content (meeting dates, skipped dates with reasons), and next-step routing. What remains unstated — e.g. how dates are ordered or how conflicts between holidays and reading weeks are resolved — is modest given the output schema exists.

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 holidays and reading_weeks is already documented with formats and examples. The description's input list largely restates the schema (weekdays names or codes, date formats), adding no new semantics. 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: 'Generate the meeting dates for a recurring class between two dates, and skip holidays and reading weeks.' This is clearly distinguishable from siblings like extract_schedule_events (which presumably reads a schedule) and names build_ics as the downstream tool, so an agent can route correctly.

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 from the example prompt ('My biology class meets Tuesday and Thursday... Skip the reading week') and the next-step hint toward build_ics. However, it never explicitly says when NOT to use this versus extract_schedule_events or merge_calendars, leaving the sibling boundary to inference.

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=false, and the description adds genuinely new behavior: undated lines are surfaced in undated_lines rather than silently dropped, events are classified into seven types, and the response ends with a next-step hint. That is meaningful disclosure of output behavior and failure handling beyond the safety hints.

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, followed by mechanics and a concrete example prompt that anchors the format. Slight redundancy in re-listing the three inputs, which the schema already documents, keeps it from being fully tight.

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 and annotations covering the safety profile, the description fills the remaining gaps well: the line-per-event parsing contract, the event taxonomy, what happens to undated lines, and the downstream build_ics step. Adequate for an agent to call it confidently; only the recurring-class handoff is 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%, so the baseline is 3. The description restates all three parameters ('text', 'course', 'year') but largely paraphrases the schema text, adding only the framing that course goes 'on every event' and year resolves dateless dates -- no syntax or edge-case detail 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?

States a specific verb and resource -- 'Extract dated events from pasted syllabus text' -- and immediately explains the one-event-per-line mapping rule. None of the siblings (expand_recurring_classes, build_ics, merge_calendars) do parsing, so the boundary is unambiguous even without naming 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?

The input precondition is explicit (pasted syllabus/course schedule text, one event per line), and the description routes the agent onward to build_ics when events should become a calendar. It does not address whether recurring class lines should instead go to expand_recurring_classes, which is the one plausible ambiguity among 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 declare readOnlyHint=false and openWorldHint=false. The description adds useful specifics beyond annotations: optional .ics file output via output_path, UID-based deduplication, and expansion of weekly/daily recurrence during conflict checking. It does not contradict 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 and the description is compact. The 'Inputs:' list is somewhat redundant with the schema, and the example prompt adds length, but both remain useful and structured.

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 needn't be explained. The description covers inputs, deduplication, recurrence handling, and optional file output, which is sufficient for correct invocation, though subtle details like whether all-day events are excluded from conflict checks remain 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 description coverage is 100%, so the schema already documents all parameters. The description restates the inputs and their optionality but adds little format or semantic detail 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?

States a specific verb and resource: 'Merge several course calendars into one' and adds conflict listing. This clearly distinguishes it from siblings like extract_schedule_events, expand_recurring_classes, and build_ics by combining merge and overlap detection.

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?

Provides a clear use case through the opening sentence and the example prompt about merging three course calendars to find conflicts. However, it does not explicitly name alternative tools or state when not to use this tool.

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