goldseam

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

TableJSON Schema

Name	Required	Description
`package`	Yes	The goldribbon_package_v1 object an earlier GoldRibbon answer returned. Keep it for the person and send it back whole; GoldSeam keeps no copy.
`language`	No
`aspiration`	No	Optional: what the person is aiming for
`checklist_id`	No	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.
`target_unitid`	Yes	The school's IPEDS UNITID, e.g. 240620

Output Schema

TableJSON Schema

Name	Required	Description
`counts`	No	claims, comparable_courses, block_credits, checklist_lines, may_be_met, already_covered, still_needed
`limits`	No	What this answer could not do, each { code, statement }
`package`	No	The person's package, with this service's part filled
`contract`	Yes
`statement`	Yes
`suggestions`	No	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
`next_actions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 22, 2026

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"

AddedSep 22, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses that nothing is stored, that the tool is a non-committal case for prior learning review (say may, never will), and that unmatched learning becomes block credit. These are exactly the behavioral caveats an agent needs and there is no contradiction with 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.

Conciseness4/5

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

The description is dense but every clause carries operational content: program lookup, line-by-line output, block-credit fallback, epistemic caveat, and statelessness. The first sentence is slightly rhetorical and could be tightened, but overall it is structured and front-loads the core behavior.

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?

Given the rich input/output schemas and readOnlyHint, the description covers the main branches and output semantics well. It does not need to explain return values because an output schema exists, and the description resolves the important caveats such as storage and wording.

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 already describes 4 of 5 parameters, so the description adds value by specifying that package must be returned whole, that checklist_id defines the only courses considered, and that without it no course suggestion occurs. target_unitid is also clear from the schema.

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 clear resource and action: map a person's learning claims to a specific program checklist and suggest credit line by line, including which claims are supported, covered by transfer, or still needed. It references find_programs for obtaining checklist_id, which helps situate it among siblings, though it does not explicitly contrast it with alternatives.

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?

The description gives practical setup context: use a GoldRibbon package and name the target program with checklist_id from find_programs. It also explains the no-program fallback, but it does not state when to prefer this tool over siblings such as will_my_credits_transfer or draft_my_claims.

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

All goldseam tools Inspect

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.