goldseam

List Persona Transcripts

list_persona_transcripts

Read-only

The example personas whose transcripts can be used in a demonstration: each persona_id, display name and description, the schools its transcript comes from, and the transcript types it offers (official, unofficial). These are example persona transcripts of made-up people, not real students. Every answer carries its steps: the source files read, the outcome, count and elapsed ms.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_persona_transcripts"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`steps`	No
`limits`	No	What this answer could not do, each { code, statement }
`example`	No
`package`	No	The person's package, with this service's part filled
`contract`	Yes
`personas`	No	Each persona's persona_id, display_name, description, transcript_schools, transcript_types and file
`statement`	Yes
`next_actions`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful context beyond that: the data is fictional (not real students), and every response includes provenance steps (source files read, outcome, count, elapsed ms). This is solid behavioral disclosure for a read-only listing tool.

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 definition is three sentences and front-loads the key content: what personas are listed and what each entry contains. The first sentence is a long noun phrase rather than a direct verb-led statement, and the final sentence about answer steps is slightly tangential, but overall there is little waste.

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 zero parameters and an existing output schema, the description is nearly complete: it explains the listing contents, clarifies the fictional nature of the data, and notes the provenance metadata returned. The missing piece is the relationship to get_persona_transcript, which would help an agent decide between listing personas and fetching a specific transcript.

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?

The tool has zero parameters, so the baseline is 4 per the scoring rules; there are no parameter semantics for the description to clarify. The description appropriately focuses on the returned persona metadata instead.

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 clearly identifies the resource: a listing of example personas whose transcripts are available for demonstrations, including the fields returned per persona (persona_id, display name, description, schools, transcript types). It does not name the obvious sibling get_persona_transcript or explain how this listing differs from retrieving a specific transcript, so it stays at 4 rather than 5.

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 'can be used in a demonstration' and the explicit caveat that these are made-up people, not real students. However, there is no explicit when-to-use guidance relative to get_persona_transcript or other siblings, and no stated exclusions beyond the demo context.

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.