Skip to main content
Glama

Find Checklists

find_checklists
Read-only

Which checklists — the generic itinerary of requirements for an award — does this institution publish? Optional words (Computer Science, welding, computer) narrow them: they are read in the award title and the program's name, the checklist's and the program's descriptions, and the CIP's title and definition, and the checklists come back in that order (title and name matches first); or a program id. Each carries the program it belongs to, its printed notes, and its CIP code with the CIP's title and definition; pass one to get_checklist. With detail summary, each carries only its program, award, year, credential, credits, CIP code and title with the CIP family, and its wording source: no notes, descriptions or CIP definition, for building a list of a school's checklists. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "unitid": "<unitid>"
    },
    "name": "find_checklists"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoOptional page size (default 20, at most 100)
queryNoOptional words, e.g. Computer Science, welding or computer: read in titles, names, descriptions and the CIP's title and definition
detailNoOptional: full (the default: each checklist with its notes, descriptions and CIP definition) or summary (each checklist's program, award, year, credential, credits, CIP code and title with the CIP family, and its wording source)
offsetNoOptional: the next_offset from a previous answer
unitidYesThe institution's IPEDS UNITID
program_idNoOptional: one program's id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / detail
      Added value: +{
      +  "description": "Optional: full (the default: each checklist with its notes, descriptions and CIP definition) or summary (each checklist's program, award, year, credential, credits, CIP code and title with the CIP family, and its wording source)",
      +  "examples": [
      +    "summary"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Optional award words, e.g. welding"New value: +"Optional words, e.g. Computer Science, welding or computer: read in titles, names, descriptions and the CIP's title and definition"
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

With only readOnlyHint supplied, the description carries the return-shape burden and does so unusually well: it discloses match ordering ('title and name matches first'), which fields each row carries in full vs summary mode, and the conditional version_count/source_count/first_edition_seen/last_edition_seen fields plus a plain-language sentence in that case. It even explains the union behavior for records no current catalog prints, which an agent could not infer from any structured field.

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 purpose is front-loaded in the first sentence, but the body is a dense run-on of semicolon-joined clauses with an awkward '...; or a program id.' fragment. It restates schema-documented detail-mode fields at length and repeats the summary field list, so several sentences do not fully earn their place.

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?

For a six-parameter list tool with no output schema, the description is comprehensive about row contents, mode differences, ordering, and multi-form/multi-source edge cases. Pagination behavior beyond 'next_offset' (defaults, max page size, termination) is left to the schema, which is a minor but real gap.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: query words are read in award title, program name, both descriptions, and the CIP title and definition, and results are ordered by that match priority; offset corresponds to 'next_offset from a previous answer'. The detail-mode semantics are largely duplicated from the schema rather than extended.

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 resource (checklists published by an institution) and defines it inline as 'the generic itinerary of requirements for an award'. It also distinguishes itself from the single-record sibling by saying forms 'come from the one-record get, never from a list', so an agent can route correctly. The rhetorical-question framing and very long opening sentence cost it the extra point.

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

Usage Guidelines4/5

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

It gives concrete selection guidance: use detail=summary 'for building a list of a school's checklists', pass a program id to scope to one program, and supply words to narrow results. It also steers agents to get_checklist when they need the full forms. What it lacks is an explicit statement of when this tool is the wrong choice versus siblings like compare_program_checklists or checklists_requiring_learning_unit.

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.