read-ai

name

read-ai

description

Use for working with Read.ai meeting data through the Read.ai MCP server: finding meetings by date, title, participant, owner, folder, or recency; retrieving transcripts, summaries, chapter summaries, action items, key questions, topics, metrics, participants, report URLs, and recording links; and turning meeting context into digests, follow-up tasks, engineering specs, CRM notes, daily briefs, decision logs, or workspace-wide analysis. Use when the user mentions Read.ai, Read AI, meeting reports, meeting transcripts, meeting summaries, action items, or asks to convert meeting discussions into deliverables.

Read.ai

Overview

Use Read.ai as the meeting memory layer. Prefer the Read.ai MCP server when available, fetch only the meeting fields needed for the request, and turn the retrieved meeting data into the user's requested output format.

Read references/read-ai-api-and-mcp.md when you need exact server details, field names, REST fallback notes, beta limitations, rate limits, or permission behavior.

Access Check

• Look for an active Read.ai MCP tool or connector before attempting REST API work. First use tool discovery with the exact query read_ai; broad semantic searches can miss lazily exposed MCP namespaces.
• Expected Codex namespace/tools are usually mcp__read_ai.list_meetings, mcp__read_ai.get_meeting_by_id, and sometimes mcp__read_ai.create_meeting_agent. Tool names can still vary, so inspect active tools for capabilities like listing meetings and retrieving a meeting by ID.
• If the user says Read.ai is connected but no Read.ai tools are exposed, ask them to restart or toggle the read_ai MCP server, then retry exact tool discovery. Do not conclude the connector is absent solely from a broad search result.
• If the server is present but initialization or a probe fails with Auth required, Unauthorized, No access token, or Invalid token, explain that the MCP server is connected but the current Codex session has not received a usable OAuth token. Ask the user to rerun the read_ai auth flow or restart/toggle the server, then retry discovery.
• If no Read.ai MCP access is available after these checks, state that the Read.ai connector/MCP server must be connected before meeting data can be retrieved. Do not invent or infer meeting contents.
• For workspace-wide requests, use whatever the connected account can access. If results appear incomplete or a permission error occurs, explain that Read.ai admins may need to enable global report access or workspace report permissions.
• Treat all meeting data as private. Retrieve and expose only the fields required for the task.

Meeting Retrieval Workflow

1. Resolve the target window or meeting identity.

   • Convert relative dates using the user's current timezone.
   • If the user names a person, title, customer, project, or folder, list meetings across the likely date range and filter locally.
   • If the request is ambiguous, present 2-5 candidate meetings with title, date/time, owner or participants when useful, and report URL if available.

2. Fetch the authoritative meeting record.

   • Use list meetings for discovery and pagination.
   • Use get meeting by ID before making specific claims about a meeting.
   • Fetch transcript only when the user asks for detailed wording, decisions, implementation requirements, quotes, or forensic analysis.

3. Ground the answer in retrieved data.

   • Include meeting title and date when summarizing.
   • Include report URL when available.
   • Distinguish explicit transcript evidence from your own synthesis.
   • When quoting, keep excerpts short and speaker-attributed.

4. Shape the output to the user's intent.

   • Default to a concise, high-signal answer.
   • Be verbose when the user asks for detail, when the task is complex, or when a deliverable benefits from structure.
   • Avoid dumping full transcripts unless the user explicitly asks for the transcript.

Common Outputs

• Meeting digest: purpose, decisions, blockers, risks, action items, open questions, and links.
• Action register: owner, task, due date if stated, source meeting, confidence, and unresolved assignment gaps.
• Engineering spec: agreed behavior, edge cases, API/data model notes, non-goals, acceptance criteria, and traceability to meeting evidence.
• Daily or weekly brief: grouped by project/customer, highlighting decisions, promises, follow-ups, and meetings that need attention.
• CRM/customer notes: customer goals, pain points, objections, commitments, renewal or expansion signals, and next steps.
• Decision log: decision, rationale, alternatives mentioned, owner, date, and meeting source.

Handling Limits

• Read.ai API/MCP is in beta. Expect occasional auth, client compatibility, and permissions friction.
• List pagination is small. Continue pagination when the user asks for broad date ranges, workspace-wide analysis, or exhaustive searches.
• Expanded transcript and metrics fields can be slower. Request only what is needed.
• If a tool fails with auth, 401, 403, 429, or missing data, explain the likely cause and the next useful action instead of retrying blindly.