Skip to main content
Glama

Teams Read Transcript

teams_read_transcript
Read-only

Reads the transcript of a Microsoft Teams call started from a chat or of a calendar meeting (transcript_id from teams_list_transcripts) as lines «HH:MM · person: text», in this computer's time zone, oldest first. Read-only. A call needs the Microsoft 365 permission CallTranscripts.Read.All, and a meeting OnlineMeetingTranscript.Read.All and OnlineMeetings.Read; an administrator of the organization must approve the transcript one: without it the answer is consent_required and says what to ask the administrator. When the organization turned off transcript access or hides who spoke, the answer says so (speakers: false means the lines have no person). Returns at most limit lines (default 500, at most 2000); a longer transcript has truncated: true. Needs a work or school Microsoft 365 account connected with connect_m365_account.

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": {
      "transcript_id": "<transcript_id>"
    },
    "name": "teams_read_transcript"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax lines to return (default 500, at most 2000)
accountNoWhich connected Microsoft 365 account to use: its email (UPN), its id from list_m365_accounts, or its display name when unique. Leave it out to use the default account.
transcript_idYesTranscript ID from teams_list_transcripts (call:... or meeting:...)

Output Schema

NameRequiredDescriptionDefault
countNo
errorNo
linesNo
sourceNo
accountNoThe email (UPN) of the Microsoft 365 account this call used.
call_idNo
createdNo
speakersNo
truncatedNoPresent and true only when the read was cut before it had everything it was asked for.
transcript_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare read-only/open-world; the description adds substantial behavior beyond them: exact permission scopes per case (CallTranscripts.Read.All vs OnlineMeetingTranscript.Read.All + OnlineMeetings.Read), the admin-approval requirement, the consent_required failure message, organization policies that hide speakers (speakers: false), and truncation signaling. This is unusually complete disclosure for a read 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?

Purpose, format, ordering and time zone are front-loaded in one sentence, with prerequisites and failure modes after. Some material (limit default 500 / max 2000) duplicates the schema and the final sentence is dense, but nearly every clause carries operational information.

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?

For a tool with nontrivial auth requirements and org-policy edge cases, the description covers prerequisites, failure modes, and output shape; an output schema exists so return-value detail is a bonus rather than a requirement. Nothing an agent needs in order to call it correctly is missing.

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

Parameters3/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; the description restates the limit default/max and the transcript_id source that the schema already documents. It adds marginal value by tying the output format and account prerequisite to the parameters, but nothing beyond the structured fields in a meaningful way.

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 first sentence states a specific verb (reads), resource (transcript of a Teams call or calendar meeting), the exact output shape («HH:MM · person: text»), the time zone and ordering, and names the sibling that supplies the ID (teams_list_transcripts). An agent can distinguish this from teams_list_transcripts and zoom_read_transcript without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent to teams_list_transcripts for the required transcript_id and to connect_m365_account for the prerequisite account connection, which is clear contextual guidance. It stops short of explicit when-not-to-use framing beyond the org-policy failure modes (access disabled, speakers hidden), so it lands just under a full 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.