Skip to main content
Glama
maxgerlach1

Granola MCP Server

by maxgerlach1
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

Granola MCP Server (Experimental)

An experimental Model Context Protocol (MCP) server for integrating Granola.ai meeting intelligence with Claude Desktop. This uses Granola's local cache. I don't have any idea how Granola updates or maintains that cache. My guess is that it's doing a rolling context window, but storing long term notes up in AWS. So, YMMV. Use at your own risk. I will likely add a cache shipper at some point since we don't have access to Gronala's data in the cloud.

Features

  • Meeting Search: Search meetings by title, content, participants, and transcript content

  • Meeting Details: Get comprehensive meeting metadata with local timezone display

  • Full Transcript Access: Retrieve complete meeting conversations with speaker identification

  • Rich Document Content: Access actual meeting notes, summaries, and structured content

  • Pattern Analysis: Analyze patterns across meetings (participants, frequency, topics)

  • Timezone Intelligence: All timestamps automatically display in your local timezone

  • Real-time Integration: Seamlessly connects to your actual Granola meeting data

Related MCP server: granola-mcp

Quick Start

Prerequisites

  • Python 3.12+

  • uv package manager

  • macOS with Granola.ai installed

  • Claude Desktop application

  • Granola cache file at ~/Library/Application Support/Granola/cache-v3.json

Installation

  1. Clone the repository to your home directory:

    cd ~
git clone <repository-url>
cd granola-ai-mcp-server

    Important: Clone to your home directory (~) rather than ~/Documents to avoid macOS permission issues with Claude Desktop.

  2. Install dependencies with uv:

    uv sync

  3. Test the installation:

    uv run python test_server.py

  4. Configure Claude Desktop by adding to your claude_desktop_config.json:

    {
  "mcpServers": {
    "granola": {
      "command": "/Users/YOUR_USERNAME/granola-ai-mcp-server/.venv/bin/granola-mcp-server",
      "args": [],
      "env": {}
    }
  }
}

    Important:

    • Replace YOUR_USERNAME with your actual macOS username

    • Use the direct path to the virtual environment's script (not uv run) to avoid working directory issues

    • The path should point to your home directory installation

  5. Restart Claude Desktop to load the MCP server:

    # Quit Claude completely
osascript -e 'quit app "Claude"'
# Reopen Claude
open -a "Claude"

Available Tools

search_meetings

Search meetings by query string.

Parameters:
- query (string): Search query for meetings
- limit (integer, optional): Maximum number of results (default: 10)

get_meeting_details

Get detailed information about a specific meeting.

Parameters:
- meeting_id (string): Meeting ID to retrieve details for

get_meeting_transcript

Get transcript for a specific meeting.

Parameters:
- meeting_id (string): Meeting ID to get transcript for

get_meeting_documents

Get documents associated with a meeting.

Parameters:
- meeting_id (string): Meeting ID to get documents for

analyze_meeting_patterns

Analyze patterns across multiple meetings.

Parameters:
- pattern_type (string): Type of pattern to analyze ('topics', 'participants', 'frequency')
- date_range (object, optional): Date range for analysis with start_date and end_date

Usage Examples

Once configured with Claude Desktop, you can use natural language to interact with your Granola meetings:

Basic Queries

  • "Search for meetings about quarterly planning"

  • "Show me yesterday's meetings"

  • "Find meetings with David from this week"

Transcript Access

  • "Get the transcript from yesterday's ProofChat meeting"

  • "What was discussed in the Float rollback planning meeting?"

  • "Show me the full conversation from the David Tibbi meeting"

Content Analysis

  • "Analyze participant patterns from last month"

  • "What documents are associated with the product review meeting?"

  • "Search for mentions of 'schema labeling' in meeting transcripts"

Recent Meeting Intelligence

The server automatically detects and provides access to:

  • Full transcripts from recent meetings (25,000+ characters)

  • Meeting content including notes and summaries

  • Participant information and speaker identification

  • Local timezone display for all meeting times

Development

Running Tests

uv run python test_server.py

Running the Server Directly

uv run granola-mcp-server

Adding Dependencies

uv add package-name

Configuration

Claude Desktop Config Locations

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

Granola Cache Location

The server reads from Granola's cache file at:

~/Library/Application Support/Granola/cache-v3.json

Security & Privacy

  • ✅ 100% Local Processing - All data stays on your machine

  • ✅ No External API Calls - No data sent to external services

  • ✅ Granola Permissions Respected - Uses existing Granola.ai access controls

  • ✅ Read-Only Access - Server only reads from Granola's cache

Performance & Capabilities

  • Fast Loading: Sub-2 second cache loading for hundreds of meetings

  • Rich Content: Extracts 25,000+ character transcripts and meeting notes

  • Efficient Search: Multi-field search across titles, content, participants, and transcripts

  • Memory Optimized: Lazy loading with intelligent content parsing

  • Timezone Smart: Automatic local timezone detection and display

  • Production Ready: Successfully processes real Granola data (11.7MB cache files)

  • Scalable: Handles large datasets with 500+ transcript segments per meeting

Current Status

🚀 PRODUCTION READY - Successfully tested with real Granola.ai data including:

  • ✅ 39+ meetings parsed and searchable

  • ✅ 28 full transcripts with complete conversations

  • ✅ Rich meeting content from notes, summaries, and structured data

  • ✅ Timezone intelligence showing times like "17:04" instead of "21:04 UTC"

  • ✅ Speaker identification and conversation flow

  • ✅ Yesterday's meetings fully accessible with detailed content

Troubleshooting

Common Issues

"Cache file not found"

  • Ensure Granola.ai is installed and has processed some meetings

  • Check that the cache file exists: ls -la "~/Library/Application Support/Granola/cache-v3.json"

"uv command not found"

  • Install uv: curl -LsSf https://astral.sh/uv/install.sh | sh

  • Or use pip fallback in Claude config: "command": "python"

"Permission denied" or "Operation not permitted"

  • Most common issue on macOS: This happens when the server is installed in ~/Documents or other protected folders

  • Solution 1 (Recommended): Move the installation to your home directory:

    mv ~/Documents/granola-ai-mcp-server ~/granola-ai-mcp-server
cd ~/granola-ai-mcp-server
uv sync  # Rebuild venv with correct paths

    Then update the path in claude_desktop_config.json

  • Solution 2: Grant Claude Desktop Full Disk Access:

    1. Open System Settings → Privacy & Security → Full Disk Access

    2. Click the lock icon and authenticate

    3. Click "+" and add /Applications/Claude.app

    4. Toggle Claude to "On"

    5. Restart Claude Desktop

"Current directory does not exist"

  • This error occurs when using uv run with the --directory flag

  • Use the direct path to the venv script instead (see Installation step 4)

Server not appearing in Claude Desktop

  • Verify the absolute path in your Claude config

  • Check Claude Desktop logs: ~/Library/Logs/Claude/mcp-server-granola.log

  • Look for Python errors in the logs

  • Ensure the path doesn't contain spaces or special characters

  • Restart Claude Desktop after config changes

"Failed to spawn process" or "No such file or directory"

  • The Python shebang in the venv script points to the wrong location

  • Run uv sync in the project directory to rebuild the venv

  • Verify the script exists: ls -la ~/granola-ai-mcp-server/.venv/bin/granola-mcp-server

Meeting notes appear empty in Claude

  • Granola sometimes stores rich notes inside documentPanels rather than notes_plain

  • This server now reads those panels by default; set GRANOLA_PARSE_PANELS=0 in the environment to disable

  • Run python test_real_cache.py to verify that panel-backed notes produce content

Available Tools

5 tools
analyze_meeting_patternsC

Analyze patterns across multiple meetings

ParametersJSON Schema
NameRequiredDescriptionDefault
pattern_typeYesType of pattern to analyze (topics, participants, frequency)
date_rangeNoOptional date range for analysis

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits like read-only nature or response behavior. It does not add any such information beyond the tool's name.

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?

The description is concise and front-loaded, but it is minimal. It could benefit from a bit more detail without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite complete schema coverage, the description lacks context about output, behavior, and proper usage. For a tool with nested objects and no output schema, more information is needed.

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

Parameters3/5

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 adds no additional meaning to the parameters beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function of analyzing patterns across meetings, which distinguishes it from sibling tools that retrieve individual meeting details or documents. However, it could be more specific about what patterns are analyzed.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or when not to use it.

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

get_meeting_detailsB

Get detailed information about a specific meeting

ParametersJSON Schema
NameRequiredDescriptionDefault
meeting_idYesMeeting ID to retrieve details for

TDQS

B3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as the type of detailed information included, access restrictions, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, efficient but too brief given the lack of annotations; it could include more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple but the description does not specify what 'detailed information' includes or return format, leaving gaps in contextual completeness.

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

Parameters3/5

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

Schema coverage is 100% with a clear parameter description, so baseline is 3. The description adds no additional meaning beyond the schema.

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?

The description clearly states the verb 'get' and the resource 'detailed information about a specific meeting', distinguishing it from sibling tools like get_meeting_documents and get_meeting_transcript.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like search_meetings or analyze_meeting_patterns, nor any exclusions or prerequisites.

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

get_meeting_documentsC

Get documents associated with a meeting

ParametersJSON Schema
NameRequiredDescriptionDefault
meeting_idYesMeeting ID to get documents for

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided; description only states what it does but not behavioral traits like read-only nature, permissions needed, or rate limits.

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?

Single sentence, no fluff; front-loaded with purpose, but could be slightly more detailed without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with one parameter but no output schema; description lacks details about return format or content, which is needed for agent to use it effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3; description adds no extra meaning beyond the schema's parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'documents associated with a meeting', making it distinct from siblings like get_meeting_details or get_meeting_transcript.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives; no comparison to siblings or mention of prerequisites.

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

get_meeting_transcriptB

Get transcript for a specific meeting

ParametersJSON Schema
NameRequiredDescriptionDefault
meeting_idYesMeeting ID to get transcript for

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose any behavioral traits such as read-only nature, required permissions, error conditions, or return format.

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?

Single sentence that is front-loaded and to the point. No redundant words, so every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. However, it lacks any behavioral context that could help an agent handle errors or understand return data.

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

Parameters3/5

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

Schema coverage is 100%, but the parameter description ('Meeting ID to get transcript for') adds little beyond the parameter name. Baseline 3 due to high coverage, no extra meaning added.

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?

The description clearly states the verb 'Get' and specific resource 'transcript for a specific meeting', distinguishing it from siblings like get_meeting_details (details) and get_meeting_documents (documents).

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

Usage Guidelines2/5

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

No guidance on when to use or not use the tool, no mention of alternatives like search_meetings for finding meetings. Usage is only implied by the action.

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

search_meetingsA

Search meetings by title, content, or participants

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query for meetings
limitNoMaximum number of results

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must convey behavioral traits. It states the search fields but omits key behaviors: whether the tool returns full meeting details or summaries, whether it supports pagination, or if it is read-only. The limit parameter hints at maximum results, but the return format is not described.

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?

The description is a single sentence of seven words, which is highly concise. It front-loads the main action and is efficiently structured. However, it could include a brief mention of the return type without significantly increasing length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description is incomplete. It does not explain what the search returns (e.g., a list of meeting summaries with IDs), nor does it mention how the limit parameter is applied. Sibling tools are not referenced to guide the agent's flow.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents both parameters ('Search query for meetings' and 'Maximum number of results'). The description adds no extra meaning beyond the schema, meeting the baseline for full coverage.

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?

The description clearly states the tool's function as searching meetings and specifies the searchable fields (title, content, or participants). This distinguishes it from sibling tools like get_meeting_details (for a single meeting) or get_meeting_documents (for attachments), making the purpose unambiguous.

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

Usage Guidelines3/5

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

No explicit guidance is given on when to use this tool versus siblings. The description implies usage for search scenarios but lacks instructions on prerequisites, fallbacks, or alternative tools. For example, it does not mention that search results can be used to obtain meeting IDs for subsequent detail lookups.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.0.0-development
    • First observedanalyze_meeting_patterns
    • First observedget_meeting_details
    • First observedget_meeting_documents
    • First observedget_meeting_transcript
    • First observedsearch_meetings
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: analyzing patterns, retrieving details, documents, transcripts, or searching meetings. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with lowercase and underscores, e.g., analyze_meeting_patterns, get_meeting_details. No mixing of styles.

Tool Count5/5

With 5 tools, the set is well-scoped for a meeting analysis server. Each tool serves a core need without redundancy or unnecessary bloat.

Completeness4/5

The tool surface covers search, retrieval of details, transcript, documents, and pattern analysis. Missing explicit list-all meetings, but search covers that. No update/delete needed for analysis context.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Granola MCP Server

    btn0s
    F
    license
    A
    quality
    D
    maintenance
    Provides access to Granola notes, meeting transcripts, calendar events, and document panels through the Granola API, enabling search and retrieval of meeting-related content.
    7
    5
    -

  • granola-mcp

    mishkinf
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables semantic search and insight extraction across Granola meeting notes, categorizing content into themes like pain points and decisions. It provides AI assistants with tools to query meeting transcripts, summaries, and speaker-attributed quotes via a local vector index.
    MIT

  • Granola MCP Server

    EoinFalconer
    A
    license
    A
    quality
    D
    maintenance
    Integrates Granola.ai meeting intelligence with MCP clients to provide direct access to meeting notes, transcripts, and workspace organization. It allows users to search and retrieve meeting content through natural language by leveraging existing Granola credentials.
    7
    4
    MIT

  • Granola MCP Server

    NimbleBrainInc
    A
    license
    A
    quality
    F
    maintenance
    Enables searching and retrieving local Granola meeting notes, including transcripts, AI-generated summaries, and action items. It supports filtering by date or attendee and automatically reloads when the local Granola cache is updated.
    8
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maxgerlach1/granola-ai-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server