Skip to main content
Glama
Carbon Voice

Carbon Voice

by PhononX

search_transcripts

Read-only

Search conversation transcripts by meaning, not date, to find where a topic was discussed when date or conversation is unknown. Returns matched messages with the matching transcript excerpt.

Instructions

Find messages by meaning (semantic search over transcripts), with the part that matched. USE WHEN: "Where did we discuss X?" without knowing the date or conversation. Omitting workspace_id searches every workspace, one request each out of 20/min: send it when known. Someone's own words ("what did Ana say"): their search_user id in creator_ids, not the name in query. USE INSTEAD: search_message_ids for notified, mentions/tags, labels; list_messages for plain history; search_messages_by_heard_status for unread. Exact names, URLs, ticket numbers may be missed. FIRST: workspace_id comes from get_workspaces_basic_info (field id) when searching one workspace — call it first if you don't have one. EXAMPLE: {"query":"launch date decision","workspace_id":"ws-abc"} RETURNS: With workspace_id: {results: [{message_id, conversation_id, conversation_name, score, matched_chunk, ...}], scope_capped}. Without: {needs_workspace_choice, workspaces: [{workspace_id, workspace_name, result_count, best_score, scope_capped, results}], empty_workspaces, skipped_workspaces: [{workspace_id, workspace_name, reason}]}. needs_workspace_choice true: ask the user which workspace (name, count, best matched_chunk), then call again with its id. skipped_workspaces were NOT searched: tell the user; retry RATE_LIMITED ones later by id. Next page: seen ids in exclude_message_ids. scope_capped true: narrow by conversation_ids or dates. Window [start_date, end_date), both with an offset. conversation_id: null = your voice memo. matched_chunk is usually the whole transcript; for more, get_messages with the message_ids. ERROR BAD_REQUEST: A bad argument — fix the one the message names. ERROR FORBIDDEN: Not a member of workspace_id — pick one from get_workspaces_basic_info. ERROR RATE_LIMITED: 20 searches/min used — wait a minute, or retry with one workspace_id. ERROR SERVER_ERROR: Search is down — retry later and tell the user. ERROR NOT_FOUND: Search not deployed — tell the user; do not retry.

Input Schema

NameRequiredDescriptionDefault
limitNoRows per workspace, 1-50. Default 30, or 10 per workspace when `workspace_id` is omitted (then at most 100 in total, or 1 each past 100 workspaces: lowest scores cut first, each workspace keeps its best).
queryYesWhat to look for, in natural language (max 500 chars).
end_dateNoEXCLUSIVE upper bound, ISO 8601 with Z or ±HH:MM.
start_dateNoInclusive lower bound, ISO 8601 with Z or ±HH:MM.
creator_idsNoOnly messages by these users. Max 50.
workspace_idNoWorkspace to search. Omit to search all of yours.
response_fieldsNoDot-path allowlist to shrink the response, e.g. ["results.id","total"]. Omit for the full payload.
conversation_idsNoOnly these conversations; skips voice memos. Send their workspace_id too. Max 50.
exclude_message_idsNoMessage ids to leave out. Max 500.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.14.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description goes further with a 20/min rate limit, per-workspace request fan-out when workspace_id is omitted, scope_capped truncation behavior, pagination via exclude_message_ids, and full error semantics including which ones to retry. That is substantial added context, though it is dense and mixes return-shape documentation into what reads as behavior disclosure.

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?

Well structured with labeled USE WHEN / USE INSTEAD / FIRST / EXAMPLE / RETURNS / ERROR blocks, and the core purpose is front-loaded. The RETURNS and ERROR sections are long and read as a compressed manual, but with no output schema nearly all of that content is load-bearing rather than filler.

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?

Nine parameters, no output schema, and a non-trivial multi-workspace response mode are all addressed: response shapes for both scoped and unscoped calls, how to resolve needs_workspace_choice, what skipped_workspaces means, how to page, and what each error code implies. An agent has everything needed to call it and interpret the result correctly.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds cross-parameter meaning the schema cannot: omitting workspace_id fans out to one request per workspace under a 20/min budget, creator_ids must take a search_user id rather than a name from the query, and exclude_message_ids is the pagination mechanism. Those are real semantic additions beyond the per-field descriptions.

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?

Opens with a specific verb and resource: "Find messages by meaning (semantic search over transcripts), with the part that matched." It also states the mechanism (semantic vs literal) and immediately flags a limitation, so an agent can tell it apart from search_message_ids and list_messages without inspecting schemas.

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

Usage Guidelines5/5

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

Explicit USE WHEN, USE INSTEAD, and FIRST blocks name each alternative sibling and the condition that selects it: search_message_ids for mentions/labels, list_messages for plain history, search_messages_by_heard_status for unread, get_workspaces_basic_info to obtain workspace_id. It also notes exact names/URLs/ticket numbers may be missed, which is a genuine when-not signal.

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