Skip to main content
Glama
Sign In

Selenios

by com.selenios.back
OverviewDiscussionsAdmin

Get interview transcript

get_meeting_transcript
Read-onlyIdempotent

Get the transcript of one interview: speaker-attributed entries with start and end times. Accepts either the meeting meetingId or its _id. For a finished interview it is the processed transcript; for an interview in progress, or one that ended minutes ago and is not processed yet, it is the real-time transcript captured so far, flagged live: true. Transcripts can be long.

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": {
      "meetingId": "<meetingId>"
    },
    "name": "get_meeting_transcript"
  }
}

Input Schema

NameRequiredDescriptionDefault
meetingIdYesThe meeting ID (meetingId or _id), or a shared interview link (…/shared/<token>) the user pasted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / meetingId / description
      Previous value: -"The meeting ID (meetingId or _id)"New value: +"The meeting ID (meetingId or _id), or a shared interview link (…/shared/<token>) the user pasted"
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: the live:true flag for in-progress or just-ended unprocessed interviews, and a warning that transcripts can be long. It doesn't cover pagination, truncation, or what happens when the transcript isn't ready — gaps that matter given the length warning.

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?

Front-loads the resource and payload, then handles ID forms, then state behavior. Four tight sentences with no filler, though the closing 'Transcripts can be long' raises a concern without saying how to handle it.

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?

A one-parameter read tool with no output schema needs modest coverage, and the description supplies shape (speaker-attributed, start/end times, live flag) plus state semantics. Missing only edge-case behavior such as a not-yet-available transcript or how long transcripts are returned.

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% and the single parameter already documents accepting meetingId or _id (and a shared link). The description restates the meetingId/_id equivalence without adding format, validation, or error semantics, so the schema is doing the work here.

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?

States a specific verb and resource ('Get the transcript of one interview') and describes the payload: speaker-attributed entries with start and end times. It scopes to a single interview, which implicitly separates it from search_meeting_transcripts, but never names that sibling explicitly.

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?

Explains what the returned transcript means depending on interview state (finished vs in progress), which helps an agent interpret rather than choose. It gives no explicit when-to-use/when-not-to-use guidance and does not point to search_meeting_transcripts as the alternative for multi-interview or keyword lookups.

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

All Selenios toolsInspect
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.

Resources