Skip to main content
Glama

Get an oral-argument transcript

get_oral_argument
Read-onlyIdempotent

Fetch U.S. Supreme Court oral argument transcripts for a case and filter turns by Justice, advocate, keyword, or start time.

Instructions

Fetch the oral-argument transcript for a case, optionally filtered by speaker, by text, or from a point in time.

The transcript is returned as "Speaker: text" turns. Use the filters to zero in on, for example, one Justice's questions ("only Justice Scalia's questions" -> speaker="Scalia") or every turn that mentions a word (find="personhood"). A full argument is far longer than the default cap; to read one straight through, follow the note at the end of a truncated transcript, which names the part and start to continue from.

Args: term: The Term year, e.g. "2014". docket: The docket number, e.g. "14-556". speaker: Case-insensitive substring of a speaker's name; include only their turns (e.g. "Scalia", "Verrilli", "Roberts"). speaker_type: "justice" or "advocate" to include only that group. Someone who argued the case before joining the Court (Kagan as Solicitor General, say) counts as an advocate. find: Case-insensitive text; include only the turns that contain it (e.g. "corporate", "personhood"). Combine with speaker_type for what one side said about it. start: Resume at this point in the recording, as "H:MM:SS", "M:SS", or seconds. Turns before it in the first selected session are skipped; give part as well when there are several sessions. part: For arguments split into sessions, the 1-based session index; default is all sessions. include_timestamps: Prefix each turn with its start time (H:MM:SS). max_chars: Soft cap on transcript length, 1000-200000 (default 18000). When hit, output is truncated with a note that says where to continue from.

Input Schema

NameRequiredDescriptionDefault
findNo
partNo
termYes
startNo
docketYes
speakerNo
max_charsNo
speaker_typeNo
include_timestampsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only, open-world, and idempotent behavior. The description adds substantial context beyond that: the transcript is returned as 'Speaker: text' turns, output is truncated at max_chars with a note explaining how to continue, speaker_type has a nuanced definition, and session/part semantics are described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is front-loaded with the core action and return format, then uses a well-organized Args section. Despite its length, every sentence provides necessary operational detail for a nine-parameter tool with no schema descriptions.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, nine parameters, no output schema, and zero schema-description coverage, the description is complete enough for correct invocation. It covers return format, filtering, truncation, continuation, session handling, and timestamp behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the full burden. It does this thoroughly: every one of the nine parameters is explained with examples, formats, defaults, and edge cases (e.g., speaker_type counts Kagan as an advocate, start accepts H:MM:SS/M:SS/seconds).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Fetch the oral-argument transcript for a case.' It also identifies the optional filtering dimensions, making it easy to distinguish from sibling tools like search_cases or get_case.

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 concrete examples of how to use filters (e.g., speaker="Scalia", find="personhood") and explains the truncation-continuation workflow, but it never explicitly says when to choose this tool over siblings such as get_case or search_cases. Usage is implied rather than contrasted with alternatives.

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