SalesEQ

Agentic research across the user's calls. Give it a whole natural-language question; a retrieval agent runs many semantic and keyword searches over the same speaker-prefixed transcript chunks as search_meetings, reads promising excerpts, and returns the excerpts it judges most relevant, grouped by meeting. Takes roughly 5-30 seconds. Use it for vague, multi-part, or cross-meeting questions where you would otherwise chain several search_meetings calls, e.g. 'Which prospects pushed back on price, and how did we respond?'. For a quick lookup of a known phrase, name, or topic, use search_meetings instead: it is near-instant. Run deep searches one at a time, never in parallel: for a broad request with several angles, run one focused question after another (e.g. per rep, product, or time period) and combine the results. num_results (default 10) is the number of excerpts, one of 1, 2, 5, 10, 20, or 50. It accepts the same filters as search_meetings (scope, identity, provenance, name, date, duration, and count filters); they are hard limits on every search the agent runs. The response has the search_meetings shape: each meeting lists every excerpt the agent reported, most relevant first, with chunk_start_seconds / chunk_end_seconds for get_transcript and timestamp links. relevance_score is the agent's rank (1.0 = most relevant) and is not comparable with search_meetings scores. If deep search can't finish, fall back to search_meetings.

deep_search_meetings

Fetch JPEG frames from a meeting video at up to 8 timestamps in one call. Use this whenever visual context would help answer the user's question, even when the user hasn't explicitly requested visual inspection. Useful cases include inspecting shared screens, slides, charts, documents, and product demos, or understanding the meeting's visual setting, who is on camera, and participants' visible expressions or reactions. Use search_meetings or get_transcript to identify relevant moments when a timestamp isn't already known. get_meeting_table_of_contents can also help locate relevant discussion ranges for choosing frame timestamps, when useful. Pass every timestamp you need in timestamps_seconds rather than making separate calls: for example, several timestamps a fraction of a second apart to catch a brief facial reaction, a few across an utterance when its exact moment is uncertain, or moments spread across the meeting to compare slides. Timestamps must be within the meeting's duration (duration_seconds from list_meetings); one past the end returns an out_of_range result while the others still return. Choose max_width by need: the 320 default (~80 vision tokens per frame) shows what's on screen; 640 (~300) makes headers readable; 1280 (~1,200) makes most on-screen text readable, and higher widths add token cost without adding detail. Frames are extracted on demand from the source video; audio-only, transcript-only, and meetings without video assets cannot return images. The response includes structured metadata and, for each frame small enough to inline, a timestamp label followed by its image/jpeg content.

get_meeting_frame

Read stored AI-generated markdown summaries for one or more meetings: far cheaper than reading whole transcripts. Use meeting_ids with 1-20 IDs, even for a single meeting. Results preserve request order and include ready, no_summary, or unavailable status. An unavailable meeting does not prevent other summaries from returning. This tool retrieves existing summaries; it does not generate new ones. Use this first for questions like 'what was this call about' or 'what happened in my last meeting'; use get_transcript only when you need exact wording or the summary is unavailable. The summary is null when it hasn't been generated, most often because no speech was detected. Before falling back to get_transcript, check the meeting's has_speech flag (returned by list_meetings): when has_speech is false there is no meaningful transcript either, so report that the meeting had no speech instead of fetching it. For questions spanning several meetings (e.g. 'summarize my week'), call list_meetings with a date range, follow pagination, then fetch summaries in batches of up to 20 IDs. Use meeting_ids even for one meeting.

get_meeting_summary

Read stored chronological tables of contents for one to 20 meetings. Each entry has a title, description, and start/end seconds from the beginning of the recording. This can help show what was discussed and when, including the sequence of discussions that a summary may not convey. It can also help select focused get_transcript windows to avoid loading unnecessary transcript text, or identify relevant times to explore with get_meeting_frame. It is optional; no summary or TOC is required before using those tools. Known start_seconds and end_seconds can be passed to get_transcript for the relevant discussion. Null timestamps mean reliable timing was unavailable; do not invent a time or timestamp link. Link to a timed entry with https://app.saleseq.ai/meetings/{meeting_id}?t={start_seconds}. Results preserve request order. ready includes the stored entries; an empty array means no substantive conversation was indexed. no_table_of_contents means an accessible meeting has no saved TOC. unavailable covers missing, deleted, or inaccessible meetings without preventing other results from returning. This tool only retrieves stored data and does not generate a TOC.

get_meeting_table_of_contents

Fetch the transcript for a meeting. Returns transcript text with speaker names, timestamps, and dialogue. Use start_seconds and end_seconds to request a specific time range: this avoids loading the entire transcript for long meetings. For example, to preview the first minute, use start_seconds=0, end_seconds=60. To continue reading, use start_seconds=60, end_seconds=120. Omit both to read from the start. Each response holds at most max_chars characters (default 80,000, about an hour of talk; up to 100,000). When a page is cut, next_start_char is set: pass it as start_char (instead of start_seconds) to read on, with the same end_seconds when reading a time window so the pages stop at its end; total_chars is the full transcript's length. Windows include overlapping utterances, or overlapping words when include_word_timings is true, so consecutive windows may repeat boundary content. If useful, get_meeting_table_of_contents can help locate a discussion and choose a focused time window without loading the full transcript first. All parameters here are SECONDS: search_meetings matches include chunk_start_seconds / chunk_end_seconds that can be passed here directly, while chunk_start_ms is milliseconds and must be divided by 1000 first. Pad the window around a search match (e.g. 60s each way) to read the surrounding context. The list_meetings tool returns duration_seconds for each meeting, which tells you the total meeting length. For 'what was this call about' questions, get_meeting_summary is much cheaper than reading the transcript. Some meetings are transcript-only (e.g. data backfills from other providers) and may not have real timestamps: in that case, timestamps are estimated at approximately 150 words per minute. Use the relevant passage's timestamp for moment links; timestamps are approximate when has_timestamps is false. When verifying multiple search_meetings candidates, fetch transcripts or time ranges for multiple candidate meetings in parallel if the client supports parallel tool calls. Utterance timestamps only mark when each speaker turn starts and ends. To find exactly when something was said, first locate the passage, then call again with include_word_timings: true and a window of at most 600 seconds around it. Every word is then annotated with its start time in seconds (hundredths), e.g. `so[310.00] the[310.21]`, which can be passed straight to get_meeting_frame, for example to catch a facial reaction just after a word. Word timings make the transcript several times larger, so never use them for general reading. When word_timings_available is false, the same window is returned without them.

get_transcript

Get lightweight organization context for the caller: org id/name, the current user's member record, and matching org members with user IDs, names, emails, roles, and membership status. Use this when you need to resolve a teammate's name or email to a SalesEQ user_id before calling other tools. For example, to search Austin's recorded calls, first call get_org_context with member_query='Austin', then call search_meetings with recorded_by_user_id containing Austin's user_id. Use member_limit and member_offset for simple member pagination (default limit 50, max 200). This tool does not return meetings, transcripts, groups, or permission graphs.

get_org_context

List meetings the user owns or received through a direct or group share, most recent first by default. `scope` is required: use `scope: 'mine'` for only meetings the user owns, or `scope: 'all_viewable'` for those meetings plus direct and group shares. Results include title, participants, duration, conversation platform, source provider, import method, and owner/importer/recorder identity. Use this to find a meeting ID, then call get_meeting_summary for a quick overview or get_transcript to read the transcript. Use owner_user_id, imported_by_user_id, or recorded_by_user_id for an exact user ID (resolve with get_org_context). Each listing ID filter accepts one ID; search_meetings accepts lists. Use owner_contains or imported_by_contains for current profile names/emails, and recorded_by_contains or exact recorded_by_email for original recorders, including external people. These roles may differ; a participant is not necessarily an owner or recorder. Filter conversation_platform for Zoom/Teams/Google Meet, source_provider for Fathom/SalesEQ, and ingestion_method for how it arrived. Provenance lists match ANY selected value; different filters combine with AND. Generic zoom/teams include web/desktop variants. Use `meeting_participant` for a partial participant name/email match, whether or not they spoke. Use `meeting_speaker` when the person must have spoken at least one word. There is no topic search here; use search_meetings for transcript/topic search. Use started_after / started_before (ISO 8601 timestamps with Z or a timezone offset) to list a date range: start inclusive, end exclusive. For calendar dates, use midnight in the user's timezone through midnight after the last day. Keep the same filters and sort when following next_cursor. Use `sort_by` / `sort_order` to scan by recency or duration, `has_speech` to include/exclude recordings with no detected speech, and `min_duration` / `max_duration` to skip very short test recordings. When `participants[].name` is null (participant identification isn't always populated), use `participants[].spoke` and `word_count` to distinguish speakers from detected silent attendees. To inspect the start of an unnamed-speaker meeting, call get_transcript with `start_seconds: 0, end_seconds: 90`: people typically introduce themselves at the start of a call.

list_meetings

Transcript search across the user's calls. This searches an index containing speaker-prefixed transcript chunks, vectorized roughly like `John Smith: I can make the call.\nJames Doe: Great, let's follow up tomorrow.` The speaker names and spoken words are both in the searchable text. Use this first when the user asks to find meetings 'about X', 'where we discussed Y', or 'that mentioned Z'. It ranks meetings by transcript relevance and returns each meeting's best-matching snippets with playback offsets (chunk_start_ms) and a relevance score. Only meetings the user owns or received through a direct or group share are returned, so results can be fewer than top_k after authorization and stale-index filtering. Default mode is hybrid: ColBERT-style late-interaction semantic ranking with a 1.3x lexical boost. Keep each query focused and at most 512 characters; use separate searches for distinct ideas. Use mode 'semantic' for pure semantic ranking, or 'bm25' for exact terms/names/IDs. Available filters include scope (mine means owned by the caller), meeting_id, owner_user_id, imported_by_user_id, recorded_by_user_id, recorded_by_email, owner_contains, imported_by_contains, recorded_by_contains, conversation_platform, source_provider, ingestion_method, chunk_speaker, meeting_speaker, meeting_participant, started_after, started_before, duration bounds, speaker/participant-count bounds, is_audio_only, and is_transcript_only. Identity ID/email and provenance filters accept lists: ANY value within a list, AND across filters. Use started_after / started_before (ISO 8601 timestamps with Z or a timezone offset) for a date range: start inclusive, end exclusive. For calendar dates, use midnight in the user's timezone through midnight after the last day. conversation_platform is where a call happened (zoom/teams include web and desktop); source_provider is where SalesEQ obtained it (e.g. fathom); ingestion_method is how it arrived (e.g. backfill). Participant/speaker name filters accept one name or a list of names with OR semantics. The default name match mode is partial, case-insensitive; use regex only for deliberate name patterns. chunk_speaker applies to the returned chunk; meeting_speaker applies to speakers anywhere in the meeting; meeting_participant applies to meeting participants whether or not they spoke. Indexed names can be resolved names or fallback labels such as `Speaker 1`, and both behave like normal searchable names. For broader fuzzy person search, include the name in query text too. Use get_org_context to resolve a teammate's name/email to recorded_by_user_id for calls they recorded, owner_user_id for calls they own, or imported_by_user_id for calls they imported. Alternatively, owner_contains/imported_by_contains match current profile names/emails; recorded_by_contains matches stored recorder attribution. External recorders may have no SalesEQ user ID: use recorded_by_email for exact matching. If useful, run multiple searches in parallel for distinct ideas from the user's request, with different phrasings, modes, or filters, then compare results. Search is often paired with get_transcript: use the returned meeting_id to read the full meeting or a focused time range to verify the broader context. Each match includes chunk_start_seconds / chunk_end_seconds, which are already converted to seconds for get_transcript: chunk_start_ms and chunk_end_ms are milliseconds (playback offsets), so never pass those to get_transcript without dividing by 1000. Use chunk_start_seconds to construct a timestamp link to a matching passage. For broad or multi-part research questions where you would otherwise run many searches, consider deep_search_meetings.

search_meetings