Check Schedule Conflicts

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

There are no annotations, so the description must carry the behavioral burden. It does disclose that the tool checks for conflicts and returns a timetable, and it explains the selection format including the optional CRN. However, it does not mention auth requirements, side effects, failure behavior, or how conflicts are represented, leaving meaningful gaps.

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 two sentences long, with the core purpose and output front-loaded in the first sentence and the key selection-format detail in the second. Every word adds information and no space is wasted on repetition of the title or schema.

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?

The presence of an output schema reduces the need to explain return values, and the description covers the main selection semantics. Still, with no annotations and an unexplained 'level' parameter, an agent may not have enough context to use the tool correctly in all cases. The definition is adequate but not fully complete.

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 0%, so the description must compensate. It adds real value for the selections parameter by defining each item as {code, crn} and explaining when CRN can be omitted. However, the 'level' parameter is not explained beyond its default value 'LS', so one of two parameters remains semantically under-specified.

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 clearly states the tool's function: 'Check a candidate set of sections for time clashes' and explicitly states the return value: 'return the resulting weekly timetable.' This is specific about the verb, resource, and output, and it is clearly distinct from sibling schedule-retrieval tools.

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?

Describing the input as a 'candidate set of sections' clearly indicates this tool is for hypothetical schedule checking, not for retrieving an actual registered schedule. It does not name alternatives or provide explicit 'when not to use' guidance, 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.