Skip to main content
Glama

Suggest Credit For My Learning

suggest_credit_for_my_learning
Read-only

Where is a person in the program they are aiming for, and what may their learning meet? Name the program with checklist_id (find it with find_programs at that school) and the answer is that program's checklist line by line: the lines their claims may meet, each with the claim, how well it is corroborated and every link cited; the lines a transfer answer in their package already covers; and the lines still needed. Learning no line matches stands as block credit. Without a program, no course is suggested and the claims stand as block credit. Each suggestion is a case to put to the school's prior learning review, never a promise: say may, never will. Nothing is stored: the answer returns the package with the suggestions for the agent to keep.

Input Schema

NameRequiredDescriptionDefault
packageYesThe goldribbon_package_v1 object an earlier GoldRibbon answer returned. Keep it for the person and send it back whole; GoldSeam keeps no copy.
audienceNoOptional: who the answer is for. student (the default): a course at the target school itself is met from the student's own transcript, or as entered, unless its grade is failing (F, U, NC) or withdrawn (W). institution: the target's own course counts only with explicit earned-credit or completion evidence. Carried in continue.arguments; send it back unchanged.
languageNo
aspirationNoOptional: what the person is aiming for
checklist_idNoThe program the person is aiming for, from find_programs or find_checklists at that school. Its lines are the only courses considered; without it no course is suggested.
target_unitidYesThe school's IPEDS UNITID, e.g. 240620

Output Schema

NameRequiredDescriptionDefault
countsNoclaims, comparable_courses, block_credits, checklist_lines, may_be_met, already_covered, still_needed
limitsNoWhat this answer could not do, each { code, statement }
packageNoThe person's package, with this service's part filled
contractYes
statementYes
suggestionsNounitid, school, checklist_id, program, checklist (every line in its own order, each may_be_met with the claim, band and cited chain, already_covered, or still_needed), comparable_courses, block_credits, affirmed_not_pursued
next_actionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / audience
      Added value: +{
      +  "description": "Optional: who the answer is for. student (the default): a course at the target school itself is met from the student's own transcript, or as entered, unless its grade is failing (F, U, NC) or withdrawn (W). institution: the target's own course counts only with explicit earned-credit or completion evidence. Carried in continue.arguments; send it back unchanged.",
      +  "enum": [
      +    "student",
      +    "institution"
      +  ],
      +  "type": "string"
      +}
  2. Changed4 schema fields changed
    • changedInput schema / properties / checklist_id / description
      Previous value: -"Optional: a program's checklist at that school; each course then names the lines it answers"New value: +"The program the person is aiming for, from find_programs or find_checklists at that school. Its lines are the only courses considered; without it no course is suggested."
    • addedInput schema / properties / checklist_id / examples
      Added value: +[
      +  "CK_225070_05e6e123"
      +]
    • changedOutput schema / properties / counts / description
      Previous value: -"claims, comparable_courses, block_credits"New value: +"claims, comparable_courses, block_credits, checklist_lines, may_be_met, already_covered, still_needed"
    • changedOutput schema / properties / suggestions / description
      Previous value: -"unitid, school, comparable_courses (each with claim, course, learning_unit, satisfies, statement), block_credits, affirmed_not_pursued"New value: +"unitid, school, checklist_id, program, checklist (every line in its own order, each may_be_met with the claim, band and cited chain, already_covered, or still_needed), comparable_courses, block_credits, affirmed_not_pursued"
  3. Added

TDQS

A4/5.0
Behavior5/5

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

Beyond the readOnlyHint, the description discloses critical non-obvious behavior: nothing is stored, the package comes back with suggestions for the agent to keep, and results are advisory ('a case to put to the school's prior learning review, never a promise: say may, never will'). That last line is genuine output-framing guidance an agent could not derive from annotations or schema, and it does not contradict readOnlyHint.

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?

Every sentence carries substance — output shape, fallback behavior, advisory framing, no-storage — but the prose is dense and run-on, with the key action buried after an oblique opening question and semicolon-chained clauses. It is informative but not front-loaded for fast scanning.

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 tool with nested objects, an output schema, and audience-dependent evaluation rules, the description covers the round-trip package contract, the checklist dependency, and the nature of the returned suggestions. It leaves audience semantics entirely to the schema, but with an output schema present it need not explain return values, so coverage is nearly 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 coverage is 83%, so the schema already documents package, audience, checklist_id, and target_unitid thoroughly. The description reinforces the checklist_id consequence ('the lines their claims may meet... without it no course is suggested') but adds little beyond what the schema properties already state, and says nothing about audience or target_unitid that the schema does not.

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 conveys a specific operation — mapping a person's learning claims line-by-line against a named program's checklist and returning which lines may be met, already covered, or still needed. It names find_programs as the way to obtain checklist_id, which differentiates it from lookup siblings. However, the opening is a rhetorical question ('Where is a person in the program they are aiming for...') rather than a direct verb+resource statement, so the purpose is clear but requires a second read.

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 routing advice ('find it with find_programs at that school') and states the fallback behavior explicitly: without a program, no course is suggested and claims stand as block credit. It does not contrast against the many adjacent siblings (draft_my_claims, comparability_for_learning_unit, will_my_credits_transfer), so an agent must infer when this tool beats those, but the core when-to-use is unambiguous.

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.