Let the Sazabi agent read your Granola notes from design and incident reviews

Last verified on Nov 8, 2026.

The reasoning behind a production decision usually lives in a meeting: why the retry limit is three, who agreed to defer the migration, what the on-call said about the last failure. Granola captured it in notes and transcripts, and its MCP server lets the Sazabi agent read them. When the agent finds a behavior in your logs, it can look for the conversation that explains why the system works that way.

What the Sazabi agent can do with Granola

Sazabi connects to Granola's MCP server at mcp.granola.ai/mcp. You approve access once in a browser with OAuth, and Sazabi refreshes the token afterward. Granola's tools, from its documentation:

• list_meetings returns meeting ID, title, date and attendees, and on paid plans can be filtered by folder. get_meetings reads the notes, private notes and summaries.
• get_meeting_transcript returns the raw transcript, on paid plans only.
• get_meeting_attachment returns screenshots of screens shared in the meeting, such as slides, charts or code.
• list_meeting_folders (paid) lists folders with their note counts, and query_granola_meetings is Granola's own chat over your meetings.
• get_account_info and switch_workspace tell you which account and workspace the connection is using.

All of these read. Nothing in Granola's documented tool list edits or deletes a note.

Access works differently from most connectors, so plan for it. Each connection acts as one Granola user and sees only that user's active workspace. Granola says MCP never combines notes across workspaces, and notes created in another workspace are not included even if sharing makes them visible in the active one. Free plans see personal notes and public notes from the last 30 days, and Enterprise admins choose which scopes members get. Granola cites a rate limit of around 100 requests per minute.

Questions it answers

• What did the team decide about this behavior in the last design review?
• Who said the migration would be deferred, and when?
• What was on the architecture slide shown in that meeting?
• Which meetings in the platform folder mention this service?
• Are there remaining action items from the incident retro?

A worked example: why does the job retry only three times

Your logs show settlement-job giving up after three attempts, and a customer wants it to try longer. Nobody remembers why three. You ask:

Which Granola account and workspace are you connected to? Then list meetings
from the last 60 days with "settlement" in the title or notes. Read the notes for
the most relevant one, and if the retry limit comes up, pull the transcript
passage and any slide that was shared.

The agent calls get_account_info first and tells you the workspace, which catches a connection pointed at the wrong workspace. It then calls list_meetings, reads the likely candidates with get_meetings, and, if the notes mention the retry limit, calls get_meeting_transcript for the exact wording and get_meeting_attachment for any shared slide.

What comes back is a rationale. If the transcript says the limit was chosen to protect a partner API from overload, then raising it is a trade and not just a fix, and you should check current partner limits before you change it. If the notes say three was a placeholder, you have permission to revisit it. If nothing turns up, check which workspace and plan you are on before assuming no meeting happened. The agent can only report what the note says. A note is a summary and can be wrong, so confirm anything consequential against the code, which you can connect through GitHub.

How it fits with other integrations

Granola and Circleback both cover meeting records, so connect whichever your team uses. Notion holds the written runbooks that meetings tend to refer to, Linear tracks the work they create, and Slack hosts the thread. Everything else is under integrations, and plans are on pricing.