Skip to main content
Glama

goldseam

by com.ksaworks
OverviewDiscussionsAdmin

Learning Units

learning_units
Read-only

What courses does this institution publish? Filter by subject abbreviation, course code (spaces and case ignored), or title words; each course carries its published credit string verbatim (ranges stay ranges), edition, and the captured page. 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
codeNoOptional course code, e.g. BIO 201
limitNoOptional page size (default 50, at most 100)
queryNoOptional title words
offsetNoOptional: the next_offset from a previous answer
unitidYesThe institution's IPEDS UNITID
subjectNoOptional subject abbreviation, e.g. BIO
unit_typeNoOptional learning-unit type, one of the answer's unit_types, e.g. course

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / unit_type
      Added value: +{
+  "description": "Optional learning-unit type, one of the answer's unit_types, e.g. course",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / subject / examples
      Added value: +[
+  "RNSG"
+]
    • addedInput schema / properties / unitid / examples
      Added value: +[
+  "225070"
+]
  3. Added

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful shape information beyond that: conditional fields (version_count, source_count, first/last_edition_seen appear only for multi-form or multi-source records), verbatim credit strings where ranges stay ranges, and the fact that a record can survive without any current catalog printing it. Pagination behavior and ordering are not disclosed.

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 purpose is front-loaded, but the remainder is a dense run-on chain of clauses mixing filter behavior and return-shape trivia ('reads exactly as it always has', 'the Union keeps a record no current catalog prints'). Several sentences describe output detail in prose that is harder to parse than the structured fields would be, and the text is far longer than the tool's filter behavior warrants.

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

Completeness3/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 carry the return-shape burden, and it does describe row fields (source_url, capture_file, catalog_year, version_count, edition spans) and their conditional presence. However it omits ordering, total counts, and how offset/next_offset round-trips, leaving gaps for a paginated list tool.

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 baseline is 3, but the description adds real meaning beyond the schema: it tells the agent that course-code matching ignores spaces and case, which the schema does not say, and names the subject/code/title filter axes. It does not clarify unit_type or offset/linkage to the prior answer beyond what the schema states.

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 opening states a specific resource and action ('what courses does this institution publish') and lists the filter axes, so an agent knows this is a filtered course listing. It also explicitly distinguishes itself from the single-record get ('the forms themselves ... come from the one-record get, never from a list'), which is valuable sibling differentiation. It does not, however, differentiate itself from search_programs_and_learning_units, the closest-looking sibling.

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 filter list and by the exclusion of the detail get, but the description never states when to prefer this over search_programs_and_learning_units or when a unitid-only browse is appropriate. The 'use the get for forms' note is a partial when-not, not a full routing rule.

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

All goldseam toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources