Overview
get_note_transcript returns the full transcript of a note as paragraphs of speaker-attributed segments, plus note metadata. The shape is uniform whether or not the note has diarization data: every paragraph carries a segments[] array, and each segment has a content string and a speaker object (or null). Both content and speaker.name are HTML-stripped at the MCP layer.
Primary Use Cases:
- Quoting exact words spoken in the meeting.
- Knowing who said what — the per-segment
speakerfield is the primary use case for this tool. - Slicing the transcript by time range using the structured
paragraphsarray. - Analyzing conversation context when documents don’t capture the wording you need.
- Uniform shape: every paragraph contains
segments[]regardless of diarization availability. - Speaker info:
segment.speakeris{label, name}when diarization exists,nullotherwise. - HTML-stripped at the MCP layer (
contentandspeaker.nameare both sanitized).
Free or unpaid notes may return a partially masked transcript. When a note exceeds the free usage limit and isn’t on a paid plan, the
content of paragraphs past the limit comes back masked. Length and structure stay the same, but the words are replaced with placeholder characters, so it reads as gibberish instead of the real speech. If a transcript looks like it cuts off partway, that’s almost always this masking, not a bug. Starting a paid plan unlocks the note and returns the full transcript.Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
noteGuid | string | Yes | Unique note identifier |
noteGuid (required)
The unique identifier of the note to retrieve. Example:- Use
list_notes(lightweight) to find candidates by folder, date, or keyword. - Use the
noteGuidfrom the result. If you also need document content for context, fetch it viasearch_notesfirst; only fall back to this tool when verbatim spoken words are required.
Response Format
Success Response — Diarized Note
When the note has diarization data, paragraphs contain one or more segments and each segment’sspeaker is an object with label (engine-assigned, stable within the note) and name (resolved person name, or null when the speaker is unmapped):
Success Response — Non-Diarized Note
When the note has no diarization data, each paragraph is reduced to a single segment whosespeaker is null. The shape is identical otherwise — callers can iterate over paragraphs[].segments[] without branching:
| Field | Type | Description |
|---|---|---|
noteGuid | string | Unique note identifier. |
title | string | Note title. |
participants | string[] | Participant names (or emails when names are unavailable). |
createdAt | string | ISO 8601 creation timestamp. |
recordingDurationSeconds | number | Recording length in seconds. |
paragraphs[] | array | Structured paragraphs. Each paragraph is a time-bounded chunk containing one or more speaker-attributed segments. |
paragraphs[].timeFrom | string | null | ISO 8601 start time of the paragraph. |
paragraphs[].timeTo | string | null | ISO 8601 end time of the paragraph. |
paragraphs[].segments[] | array | Speaker-attributed slices of the paragraph. Always non-empty when the paragraph is returned (empty segments and empty paragraphs are filtered out). |
paragraphs[].segments[].content | string | HTML-stripped plain-text content of the segment. |
paragraphs[].segments[].speaker | object | null | {label, name} when diarization data is available; null otherwise. |
paragraphs[].segments[].speaker.label | string | Diarization-engine label (e.g. SPEAKER_0). Stable within a single note. |
paragraphs[].segments[].speaker.name | string | null | Resolved person name when the user has mapped the speaker; null otherwise. |
Migration
The pre-2026-05-06 response carriedtranscription (a joined string), paragraphs[].text (per-paragraph plain text), hasDiarization, and totalParagraphs. All four are gone. They can be reconstructed from the new shape:
segments[].speaker directly — that’s the new primary use case for this tool.
Usage Examples
Example 1: Basic Usage
AI Request:Example 2: Progressive Disclosure Pattern
Step 1: Searchsearch_notes - Fast (~1 second, ~100 tokens)
Step 2: Summary
get_note(include: ['summary']) - Medium (~2 seconds, ~500 tokens)
Step 3: Full Transcript (Only if Needed)
get_note_transcript - Slow (~5 seconds, ~4,000 tokens)
Token Usage
Typical Meeting (1 hour): ~3,000-5,000 tokens Compared to the pre-2026-05-06 shape, single-speaker notes see ~30% reduction because the redundanttranscription joined string is no longer emitted. Multi-speaker (diarized) notes are roughly equivalent — the per-segment speaker metadata replaces the old transcription payload, and the segment content is the same data the old text field carried.
Comparison (3-tier discovery):
| Tool | Token Usage | When to Use |
|---|---|---|
list_notes | ~50 tokens per note | Finding which notes exist (metadata only) |
search_notes | ~1,500 tokens per note | Reading the content behind a topic (returns documents) |
get_note_transcript | ~3,000-5,000 tokens per hour | Last resort — exact spoken words for quoting |
get_note(include: ['summary']) | ~200-800 tokens | Quick AI summary of one note |
get_note(include: ['documents']) | ~300-2,000 tokens | Specific generated document |
Best Practices
Use Progressive Disclosure (3-tier)
Use Progressive Disclosure (3-tier)
Always follow this order:
- list_notes — find which notes exist (~50 tokens per note)
- search_notes — read the documents for a matched topic (~1,500 tokens per note)
- get_note_transcript — only if exact wording is required (~4,000 tokens per hour)
When to Use Transcripts
When to Use Transcripts
Use full transcripts when you need to:
- Find exact quotes or statements
- Analyze detailed conversation flow
- Understand complete context
- Reference specific discussions
- Know who said what — the
segments[].speakerfield makes this a primary use case for this tool.
- Quick overview (use
get_note(include: ['summary'])instead) - Action items (use
get_note(include: ['documents'])) - General understanding (use
get_note(include: ['summary']))
Handle Large Transcripts
Handle Large Transcripts
For very long meetings (2+ hours):
- Expect 5,000-10,000 tokens
- May cause timeout (60 seconds)
- Consider requesting specific sections via summary first
- Use summary to identify relevant parts before loading full transcript
Common Errors
Missing Note GUID
Solution: Provide thenoteGuid parameter.
Note Not Found
Possible Causes:- Note doesn’t exist
- Note has been deleted
- You don’t have access to this note
search_notes.
Request Timeout
Causes:- Very long meeting transcript (2+ hours)
- Server load
- Use
get_note(include: ['summary'])instead - Retry after a short delay
- Contact support if problem persists
Performance
Response Time:| Meeting Length | Tokens | Response Time |
|---|---|---|
| 30 minutes | ~1,500 | ~2 seconds |
| 1 hour | ~3,000 | ~3 seconds |
| 2 hours | ~6,000 | ~5 seconds |
| 3+ hours | ~9,000+ | ~8 seconds (may timeout) |
Cache BehaviorTranscripts are cached for 15 minutes. Subsequent requests for the same note will be faster.