Search and read your recorded meetings: notes, action items, participants, transcripts.
Scored across 5 tools
The set is effectively three capabilities (list, search, read) exposed as five tools, with `fetch`/`get_meeting` and `search`/`search_meetings` being exact duplicates. The descriptions do explicitly explain the duplication (ChatGPT connector compatibility) and warn against misuse, which prevents outright misselection, but an agent still has to reason about which alias to pick.
Two naming conventions coexist: bare verbs (`fetch`, `search`) alongside verb_noun names (`get_meeting`, `list_meetings`, `search_meetings`). Worse, the same operation is named differently across the pair (`search` vs `search_meetings`, `fetch` vs `get_meeting`), breaking any predictable pattern.
Five tools is within a reasonable range for a read-only meeting archive, but two of them are pure aliases, so 40% of the surface is redundant. The count is defensible only because of an external platform constraint rather than genuine scope.
For a read-only synced-meeting domain, the surface covers the core lifecycle: enumerate the archive, keyword-search across notes/transcript, and read a full meeting with pagination and time-range windows. Minor gaps exist — no cross-meeting action-item aggregation or participant-centric listing — but agents can work around these via search.
Same read as get_meeting: one meeting's notes, action items, participants, and speaker-labeled transcript with timestamp links where recorded, paged for long meetings — the end of text says how to get the next page (pass its cursor). Cite the closest timestamp for exact quotes and decisions. Exists because ChatGPT's connector surface requires a tool named fetch; other clients should call get_meeting.
Use with an id from search. Do not use to find a meeting by topic (search / search_meetings).
Does not create, edit, or delete meetings. Unknown ids return an error.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Meeting id from search, e.g. "mtg-1786560198190". | |
| cursor | No | Continue reading: pass the previous page's next_cursor unchanged. A search hit's cursor works too and opens the transcript at that hit. | |
| end_minute | No | Stop before this minute (e.g. 122). With start_minute, reads one stretch of a long meeting; it still pages if the stretch is long. | |
| start_minute | No | Start the transcript at this minute of the meeting (e.g. 60). Ignored when cursor is set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the description does not need to repeat that. It does add real behavior the annotations cannot express: transcripts are paged, the next-page instruction lives at the end of `text`, and unknown ids return an error. The "does not create, edit, or delete" line restates the destructiveHint annotation rather than adding to it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The payload-defining sentence comes first, followed by paging, citation guidance, the naming rationale, and then usage constraints. Dense but well ordered. The one meta sentence about ChatGPT's connector surface earns its place as routing guidance, though it is the most expendable line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it names every returned component and explains how to continue past the first page. Combined with the error behavior and citation advice, nothing needed to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters; baseline would be 3. The description goes slightly further by explaining the paging loop (pass the cursor, the end of `text` tells you how) and tying `cursor` to search hits opening at the matched transcript position, which clarifies how the parameters interact across calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb and resource (read one recorded meeting) plus an enumeration of the returned content: notes, action items, participants, speaker-labeled transcript with timestamp links. It explicitly distinguishes itself from get_meeting ("same read as get_meeting") and from the search siblings, so an agent can place it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives positive usage ("Use with an id from search"), a negative case with the correct alternative ("Do not use to find a meeting by topic (search / search_meetings)"), and a client-based routing rule (other clients should call get_meeting). Both when and when-not are stated with alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one recorded meeting: AI notes, action items, participants, and the speaker-labeled transcript with timestamp links where recorded, all in text. Cite the closest timestamp for exact quotes and decisions. Long transcripts come back in pages; each page's transcript_page says which lines and minutes it covers, the meeting's total length, how many pages are left, and a next_cursor. To read the whole meeting, keep calling with the same id and cursor = next_cursor until transcript_page.complete is true — never treat one page as the full call. To read one stretch, pass start_minute and/or end_minute; a search hit's cursor opens the transcript at that hit. Notes come on the first page. Takes an id from search_meetings or list_meetings.
Use when you already have a meeting id and need the notes or quotes. Do not use to find a meeting by topic (search_meetings) or to page the archive (list_meetings). ChatGPT clients call the same read as fetch.
Does not create, edit, or delete meetings. Unknown ids return an error, not an empty meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Meeting id from search_meetings or list_meetings, e.g. "mtg-1786560198190". | |
| cursor | No | Continue reading: pass the previous page's next_cursor unchanged. A search hit's cursor works too and opens the transcript at that hit. | |
| end_minute | No | Stop before this minute (e.g. 122). With start_minute, reads one stretch of a long meeting; it still pages if the stretch is long. | |
| start_minute | No | Start the transcript at this minute of the meeting (e.g. 60). Ignored when cursor is set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, but the description adds substantial behavior the annotations cannot convey: paginated transcripts, the transcript_page metadata fields, the next_cursor loop and the warning not to treat one page as the full call, notes appearing only on the first page, ignored start_minute when cursor is set, and errors rather than empty results for unknown ids. It also states the non-mutation guarantee explicitly, matching the annotations rather than contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and payload, then pagination, then when-to-use/exclusions. Dense and nearly waste-free, though the pagination paragraph is long and the 'never treat one page as the full call' warning restates the transcript_page.complete instruction already given.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-shape burden and does so thoroughly: the `text` field, transcript_page contents (line/minute coverage, total length, pages remaining, next_cursor, complete), and where notes appear. Combined with pagination and error semantics, an agent can call and consume this tool correctly end to end.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description goes beyond it by explaining the pagination protocol (same id, cursor = next_cursor until transcript_page.complete), the start_minute/end_minute range-read pattern, and the precedence rule that a search hit's cursor opens at that hit. Minor residual gap: it does not clarify units or clamping for end_minute beyond the minute-based examples already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read one recorded meeting') and enumerates what comes back: AI notes, action items, participants, speaker-labeled transcript with timestamp links. It explicitly names the two siblings it is not (search_meetings for topic lookup, list_meetings for archive paging), so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives both sides of the decision: 'Use when you already have a meeting id and need the notes or quotes' plus explicit 'Do not use to find a meeting by topic (search_meetings) or to page the archive (list_meetings).' It also states the id source (search_meetings or list_meetings) and explains how a search hit's cursor is reused, closing the loop between search and read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's synced meetings, newest first, as metadata only — id, title, date, length, and participants, with no notes or transcript. Page by passing each reply's next_cursor back as cursor until next_cursor is null; that walk returns every meeting exactly once.
Use to build an index of the archive. Do not use when you already know what you are looking for (search_meetings) or when you need notes/transcript for one id (get_meeting).
Does not create, edit, or delete meetings. This is metadata only — it will not return what was said.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows to return. Default 50, cap 200. | |
| cursor | No | Continue listing: pass the previous reply's next_cursor unchanged. | |
| offset | No | Skip this many meetings. Prefer cursor, which cannot skip or repeat a meeting when one syncs or is deleted while you page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the cursor walk returns every meeting exactly once, and the response is metadata only with no notes or transcript. It also states it does not create, edit, or delete, reinforcing the safety profile rather than contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and return shape, then pagination, then routing guidance. Slightly redundant in repeating 'metadata only' twice, but the repetition serves the critical disambiguation from transcript-bearing siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still enumerates the returned fields and the next_cursor field needed to page, and it covers the mutation and content boundaries. An agent has everything required to call and iterate this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the next_cursor-to-cursor loop and the exactly-once guarantee, which the schema alone does not convey. It does not restate the limit cap or offset semantics, leaving those to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list the user's synced meetings) plus ordering (newest first) and exact returned fields (id, title, date, length, participants). It explicitly excludes notes/transcript, which separates it cleanly from get_meeting and search_meetings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit positive case (build an index of the archive) and two explicit negative cases with named alternatives: search_meetings when you know what you want, get_meeting when you need notes/transcript for one id. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Same search as search_meetings: keyword match across titles, notes, action items, participants, and transcript, returning ids for fetch. Exists because ChatGPT's connector surface requires a tool named search; other clients should call search_meetings.
Use when the host only exposes search/fetch, or when following ChatGPT's search-then-fetch flow. Do not use to page the archive (list_meetings) or to open a known id (fetch / get_meeting).
Does not create, edit, or delete meetings. query must be non-empty. Scans at most the 200 most recent synced meetings.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword or phrase to find. Plain-text, case-insensitive; not a boolean query language. |
| Name | Required | Description |
|---|---|---|
| total | No | |
| matches | No | |
| results | No | |
| scanned | No | |
| truncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context: it clarifies the tool does not create/edit/delete meetings (reinforcing the annotations), requires a non-empty query, and scans at most 200 recent synced meetings. It also states it returns ids for fetch, which hints at output structure. This adds value beyond annotations, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into three short paragraphs: purpose, usage, and constraints. It front-loads the primary purpose and includes only necessary details. While it repeats 'query must be non-empty' from the schema, it is not overly verbose. The structure is clear and efficient, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the rich annotations and existing output schema, fully equips an agent to call this tool correctly. It covers the search scope, the return behavior (ids for fetch), the usage context, and the 200-meeting limit. There are no obvious missing pieces that would prevent correct invocation. A 5 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for `query` is already rich (plain-text, case-insensitive, not a boolean query language). The tool description only reiterates that the query must be non-empty, which is already enforced by schema (required, minLength). Since schema coverage is 100%, the description adds minimal additional meaning, so a baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs keyword search across specific fields (titles, notes, action items, participants, transcript) and returns ids for fetch. It distinguishes itself from search_meetings by noting it is the same search but renamed for ChatGPT, and from list_meetings and fetch by its purpose. This is a specific verb-resource description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: when the host only exposes `search`/`fetch`, or when following ChatGPT's search-then-fetch flow. It also lists exclusions: not for paging the archive (list_meetings) or opening a known id (fetch / get_meeting). This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the user's recorded meetings by keyword or phrase. Matches titles, notes, action items, participant names, and the spoken transcript. Returns ids, titles, dates, participants, note headings and each meeting's transcript hits: the time, the lines around each hit, and a cursor that opens get_meeting right at that point (pass it as get_meeting's cursor).
Use when the user asks what was said, decided, or assigned on a call, or names a person or project in the context of a meeting. Do not use to browse the whole archive (list_meetings) or to open a meeting whose id you already have (get_meeting). ChatGPT clients call the same search as search.
Does not create, edit, or delete meetings. query must be non-empty (a blank query is rejected, not treated as list-everything). Scans at most the 200 most recent synced meetings; truncated means older meetings were not searched, so total is matches in that window, not the lifetime corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max matches to return. Default 10, cap 25. | |
| query | Yes | Keyword or phrase to find. Matched as plain text (case-insensitive) against titles, notes, action items, participants, and transcript — not a boolean query language. | |
| hits_per_meeting | No | Transcript hits to show per meeting, each with the lines around it and a cursor for get_meeting. Default 3, cap 10. |
| Name | Required | Description |
|---|---|---|
| total | No | Matches inside the scanned window. |
| matches | No | |
| results | No | |
| scanned | No | Meetings actually scanned (≤ 200). |
| truncated | No | True if older meetings were not scanned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world, but the description adds behavior the annotations cannot express: no create/edit/delete, blank queries rejected rather than treated as list-all, a 200-most-recent-meeting scan cap, and the meaning of `truncated` and `total` within that window. Those are exactly the runtime caveats an agent needs to interpret results honestly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The structure is front-loaded and logical: capability, return shape, when-to-use, when-not-to-use, then behavioral caveats. It is dense but nearly every clause carries information; the return-format sentence is somewhat long and partially redundant given the output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search with a full output schema, this covers everything that matters: what is matched, what comes back, how the cursor links to get_meeting, the alias, and the scanning-window limitation that changes how `total` should be read. Nothing needed to call or interpret it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, and the description does add meaning beyond the schema for `query`: it is plain-text case-insensitive matching, not a boolean query language, and an empty value is rejected rather than widening to everything. It does not add anything for `limit` or `hits_per_meeting` beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Search the user's recorded meetings by keyword or phrase') and immediately enumerates the searchable fields (titles, notes, action items, participants, transcript). It explicitly names the two siblings it is not (list_meetings for browsing, get_meeting for a known id), so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete positive trigger ('what was said, decided, or assigned on a call, or names a person or project') plus explicit exclusions mapped to the right alternatives. It even resolves the alias ambiguity by noting ChatGPT clients call the same search as `search`, which matters given `search` is a sibling name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetch3 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Continue reading: pass the previous page's next_cursor unchanged. A search hit's cursor works too and opens the transcript at that hit.",
+ "type": "string"
+}Input schema / properties / end_minuteAdded value: +{
+ "description": "Stop before this minute (e.g. 122). With start_minute, reads one stretch of a long meeting; it still pages if the stretch is long.",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / start_minuteAdded value: +{
+ "description": "Start the transcript at this minute of the meeting (e.g. 60). Ignored when cursor is set.",
+ "minimum": 0,
+ "type": "number"
+}get_meeting3 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Continue reading: pass the previous page's next_cursor unchanged. A search hit's cursor works too and opens the transcript at that hit.",
+ "type": "string"
+}Input schema / properties / end_minuteAdded value: +{
+ "description": "Stop before this minute (e.g. 122). With start_minute, reads one stretch of a long meeting; it still pages if the stretch is long.",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / start_minuteAdded value: +{
+ "description": "Start the transcript at this minute of the meeting (e.g. 60). Ignored when cursor is set.",
+ "minimum": 0,
+ "type": "number"
+}list_meetings2 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Continue listing: pass the previous reply's next_cursor unchanged.",
+ "type": "string"
+}Input schema / properties / offset / descriptionPrevious value: -"Skip this many meetings (use with returned total)."New value: +"Skip this many meetings. Prefer cursor, which cannot skip or repeat a meeting when one syncs or is deleted while you page."search_meetings1 field changedInput schema / properties / hits_per_meetingAdded value: +{
+ "description": "Transcript hits to show per meeting, each with the lines around it and a cursor for get_meeting. Default 3, cap 10.",
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+}fetchget_meetinglist_meetingssearchsearch_meetingsSearch your recorded meetings and read their speaker-labelled transcripts and AI notes.
Search and read your LiteScribe recordings: transcripts, summaries, action items, screenshots.
Read-only access to your RecordX meetings: search transcripts, summaries, action items.
Search and read your recorded meetings, calls, interviews and lectures, with speaker names.
Add one secure layer between your agents and this server.