Skip to main content
Glama

Get Checklist

get_checklist
Read-only

What does this award require? One checklist: its requirement groups (every header and full item count), each group's items with published credit strings, alternatives, and — where an item resolved to a course — that course's own code, title, and published credits, attributed to the course. Items come in pages across the groups; the answer states items_total and next_item_offset. Every row names the captured page it came from. 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
item_limitNoOptional items per page (default 60, at most 150)
item_offsetNoOptional: the next_item_offset from a previous answer
checklist_idYesA checklist id from programs_for_institution or compare_program_checklists

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / checklist_id / examples
      Previous value: -[
      -  "CK_225070_3a81edaf"
      -]New value: +[
      +  "CK_225070_05e6e123"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / checklist_id / examples
      Added value: +[
      +  "CK_225070_3a81edaf"
      +]
  3. Added

TDQS

B3.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint, so the description carries most of the burden and does so well: it discloses pagination (items come in pages, answer states items_total and next_item_offset), conditional field presence (version_count/source_count/first_edition_seen/last_edition_seen only for multi-form or multi-source records), and provenance/edition caveats. These are genuine behavioral traits beyond what the single annotation provides.

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

Conciseness3/5

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

The opening question 'What does this award require?' is a strong front-loaded hook, but the body is a dense, jargon-heavy run-on about sources, forms, and the Union. Content is largely relevant, yet it is not economical and reads as overly repetitive in places.

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?

With no output schema, the description must explain the return shape and does so extensively: requirement groups with headers and item counts, items with credits and alternatives, per-row provenance and conditional version/source fields, pagination totals. This is close to complete, though the routing/comparison case for this tool versus siblings remains unsaid.

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 coverage is 100%, so all three parameters are already documented, including item_limit defaults/caps and checklist_id sourcing. The description implies pagination flow (next_item_offset) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 states a specific verb+resource: retrieve one checklist's requirement groups, items, published credit strings, alternatives, and resolved course code/title/credits. An agent can distinguish it from list-oriented siblings like find_checklists and compare_program_checklists. It never explicitly names those siblings, but the singular 'one checklist' scope is clear.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance relative to siblings (find_checklists, compare_program_checklists, get_program). The only routing hint is negative: forms 'come from the one-record get, never from a list,' which does not tell the agent when to pick this tool over 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.