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

Annotations only provide readOnlyHint=true, so the description carries the behavioral burden and delivers materially: it discloses that held rules are consulted before live rules, that each rule carries source authority, source_url, and band, that results are comparable rather than equivalent, and that incoming 'lands on' rules come only from held data. This is valuable non-obvious behavior beyond the read-only flag.

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 only two sentences, front-loaded with the core question and free of filler. It loses one point because it packs in domain-specific terms like CourseShelf, CourseAtlas, and band without definitions, making the second sentence dense and slightly harder to parse.

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 nine parameters, none required, and no output schema, the description should clarify the identifier contract: the tool is explicitly 'for one course,' yet it never says that code, title, or learning_unit_id must identify that course (with school/unitid as disambiguators). It also leaves list/pagination behavior mostly to the limit/offset schema hints. The rule-shape detail partially compensates, but the missing selection contract is a real 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?

The schema already documents 100% of the parameters, including direction semantics and the optional school/unitid disambiguators, so the baseline is 3. The description reinforces the lands_as/lands_on distinction and the 'one course' idea but does not add parameter-specific meaning beyond what the input schema already 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 opens with a precise framing of the operation: where a course lands at other schools and what lands on it, for a single course. It explicitly identifies the domain as published transfer rules and adds a key semantic distinction, 'comparable, never equivalent,' which separates it from generic equivalence or transfer-credit tools. This is specific enough to distinguish it from sibling search, compare, and credit-transfer 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?

The description gives clear context: this tool is for one course's comparability and covers both directions by default, with a well-defined data precedence ('rules CourseShelf holds first ... then CourseAtlas's direct rules read live'). It does not explicitly name alternatives or state when-not-to-use, so it falls just short of full routing guidance.

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