Skip to main content
Glama

Get Program

get_program
Read-only

One program whole: its row, identifiers, offerings (campus resolved), its own footnotes (program_note) where held, its institution, and the checklists that lead to its award — pass one to get_checklist. 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": {
      "program_id": "<program_id>"
    },
    "name": "get_program"
  }
}

Input Schema

NameRequiredDescriptionDefault
program_idYesA program id from programs_for_institution or find_programs

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / program_id / examples
      Previous value: -[
      -  "PG_225070_28b9a863"
      -]New value: +[
      +  "PG_225070_8c96bb26"
      +]
  2. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds rich behavioral context: it explains what data is included (identifiers, offerings, footnotes, institution, checklists), how versioning and source attribution work (version_count, source_count, first/last edition), and how older-edition records are flagged. This is valuable transparency 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.

Conciseness3/5

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

The description is dense and somewhat disorganized, with long sentences and conditional clauses. It front-loads the main content but could be clearer and more structured; it is not excessively verbose for the complexity, but readability suffers.

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 single-parameter tool with no output schema, the description covers return content and versioning behavior thoroughly. However, one ambiguous sentence about where forms come from ('the one-record get') might confuse an agent about whether forms are included, leaving a minor gap.

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%, with program_id fully described. The description adds no additional meaning about the parameter itself beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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

The description clearly states a specific verb and resource: 'One program whole' with its row, identifiers, offerings, footnotes, institution, and checklists. It distinguishes from list-based siblings by noting it returns a single program and points to get_checklist for award checklists.

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: use this tool to retrieve a single program by id, and pass checklists to get_checklist. However, there is no explicit when-to-use guidance, no comparison to alternatives like find_programs or get_institution beyond the schema hint, and no when-not-to-use conditions.

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.