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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is fully covered without description help. The description adds the domain insight that dates are typically Mondays, which is useful context beyond the annotations, but it says nothing about auth requirements, rate limits, or response shape. With annotations carrying the behavioral burden, a 3 is appropriate.

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 compact sentences, each earning its place: one states what is returned, the other routes the output to the correct consuming fields. No filler or 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?

An output schema exists, so return values need not be explained, and annotations cover safety. The description supplies the key domain fact (Mondays) and the downstream usage. It is thin but sufficient for a simple lookup; only a bit more on locale effects or date format would make it 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 100%, with both parameters well documented (school_id explains it is a Craft CMS entry id, locale describes the enum values). The description adds no parameter syntax or constraints beyond what the schema provides. Baseline 3 applies when 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?

Clearly states what the tool returns: allowed course start dates for a school, with the note that they are typically Mondays. Distinguishes it from siblings like list_courses by being the source of valid startDate values. Slightly marred by the terse, table-like phrasing that names no verb, but the resource and intent are unambiguous.

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?

Explicitly instructs to use the returned startDate values in list_courses and configuration.startDate, giving a clear integration point. It does not name an alternative for retrieving start dates, but for this narrow lookup no plausible alternative exists. No when-not guidance is provided, though none seems needed.

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