goldseam

Get Persona Transcript

get_persona_transcript

Read-only

One example persona's transcript, parsed now by assemble_my_formal_education: held (the course list will_my_credits_transfer, checklist_map and comparable_map take, unchanged), courses (each course as read: school and IPEDS UNITID where it resolved, code, title, credits, grade and term; exams with their scores) and package (for suggest_credit_for_my_learning). Official and unofficial read the same transcript, labelled: official stands in for a transcript vendor request, unofficial for importing unofficial coursework. vendor_delay_ms, official only, waits that long first to show an official request may not come back at once; the wait counts against the call's time. The answer says plainly it is an example persona transcript, and carries its steps: the persona file, any vendor wait, and the parse, each with its outcome, count, elapsed ms and files.

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": {
      "persona_id": "<persona_id>"
    },
    "name": "get_persona_transcript"
  }
}

Input Schema

Name	Required	Description
`persona_id`	Yes	A persona_id from list_persona_transcripts
`transcript_type`	No	Which transcript to read; unofficial when omitted
`vendor_delay_ms`	No	Official only: milliseconds to wait first, imitating a slow transcript vendor

Output Schema

Name	Required	Description
`held`	No	The items for will_my_credits_transfer, checklist_map and comparable_map
`steps`	No
`limits`	No	What this answer could not do, each { code, statement }
`courses`	No	Each course as read from the transcript
`example`	No
`package`	No	The GoldRibbon package, for suggest_credit_for_my_learning
`contract`	Yes
`statement`	Yes
`next_actions`	No
`transcript_type`	No
`transcript_label`	No
`example_statement`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond the readOnlyHint annotation, the description discloses that vendor_delay_ms waits before returning and that the wait counts against the call's time — useful latency behavior. It also describes the step-by-step outcome reporting (persona file, vendor wait, parse with elapsed ms and files), adding real transparency.

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 description is a dense run-on chaining several sibling tool names, backticked fields, and parentheticals. While the core purpose is front-loaded, the remaining text is hard to parse and includes heavy repetition of what the output schema already provides.

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?

With an output schema present, the description need not explain return values, yet it does so redundantly. It nevertheless covers the key behavioral context (transcript type semantics, vendor delay, step reporting) needed to invoke the tool correctly.

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 meaning: it clarifies that persona_id should come from list_persona_transcripts, explains the semantic intent of official vs unofficial transcripts, and notes that vendor_delay_ms applies only to official and counts against call time.

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 clause names a specific resource ('one example persona's transcript') and the parser that produces it, so an agent knows what it gets back. However, the phrasing is tangled with sibling tool names and backticked field lists, which blurs the core verb+resource statement.

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 explains what 'official' vs 'unofficial' transcript types represent, which implicitly guides selection, but never states when to call this tool versus list_persona_transcripts or assemble_my_formal_education. Usage is inferable but not explicit.

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.