Skip to main content
Glama

Checklists Requiring Learning Unit

checklists_requiring_learning_unit
Read-only

Which checklists require this course? Each requirement item that resolved to it, with its checklist id, award and group heading. Items that did not resolve to a course are never guessed into this list. Each row names its current FORM's wording source: source_url, capture_file, catalog_year and source_catalog_name are that one source's, never the record's whole span. A row whose record holds more than one form or more than one source also carries version_count, source_count, first_edition_seen and last_edition_seen, and one sentence saying so in words; a record with one form and one source carries none of them and reads exactly as it always has. The forms themselves, each with its own content and its own sources, come from the one-record get, never from a list. A record last seen in an older edition says so, because the Union keeps a record no current catalog prints.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoOptional page size (default 20, at most 100)
offsetNoOptional: the next_offset from a previous answer
learning_unit_idYesA learning unit id from learning_units or get_learning_unit

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral burden. It discloses significant output semantics: unresolved items are never guessed, source attribution is per-form rather than record-wide, and conditional fields appear only for multi-form/multi-source records. It does not cover pagination behavior or error cases, but adds useful context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense, jargon-heavy, and includes several run-on sentences that are hard to parse. While it is front-loaded with purpose, many details about forms, editions, and provenance arrive in a single undifferentiated block. Some phrases, such as the final Union explanation, could be trimmed without losing necessary agent guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values. It does so thoroughly, covering checklist id, award, group heading, source fields, and conditional version/source counts. Pagination semantics are left to the schema, and error behavior is omitted, but for a read-only list tool the description is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description does not add meaning to learning_unit_id, limit, or offset beyond what the schema provides. Baseline 3 is appropriate 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific purpose: finding which checklists require a given course. It clearly states the resource (checklists) and relation (requiring this course). However, it does not explicitly differentiate from siblings like find_checklists or get_checklist, relying instead on the tool name and scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the purpose and by the note that forms come from the one-record get, not from this list. This gives a partial alternative for obtaining form details, but there is no explicit when-to-use guidance, no exclusions, and no named sibling alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.