Granola MCP Server
Provides access to Granola notes, documents, meeting transcripts, calendar events, and structured note panels through the Granola API, using Supabase credentials stored locally for authentication.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Granola MCP Serversearch for notes about the Q3 planning meeting"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Granola MCP Server
A Model Context Protocol (MCP) server that provides access to your Granola notes, documents, transcripts, and calendar events using the Granola API.
Features
🔍 Search Notes: Search through all your Granola documents/notes
📝 Search Transcripts: Find meeting transcripts by content
📅 Search Events: Search calendar events
📋 Search Panels: Search structured note panels
📄 Get Documents: Retrieve specific documents by ID
📊 List Documents: List all available documents
Related MCP server: Granola MCP Server
Installation
Install dependencies:
cd granola-mcp-server
npm installBuild the server:
npm run buildConfiguration in Cursor
Add this to your Cursor MCP configuration (usually in .cursor/mcp.json or Cursor Settings):
{
"mcpServers": {
"granola": {
"command": "node",
"args": ["/absolute/path/to/granola-mcp-server/dist/index.js"]
}
}
}Important: Replace /absolute/path/to/granola-mcp-server/dist/index.js with the actual absolute path to your built server.
Usage
Once configured, you can use the MCP tools in Cursor:
search_granola_notes- Search documents by querysearch_granola_transcripts- Search meeting transcriptssearch_granola_events- Search calendar eventssearch_granola_panels- Search document panelsget_granola_document- Get a specific documentget_granola_transcript- Get a specific transcriptlist_granola_documents- List all documents
How It Works
The server uses Granola's API with credentials stored locally at:
~/Library/Application Support/Granola/supabase.jsonIt fetches data from the Granola API and provides search/retrieval capabilities over:
Documents (notes)
Meeting transcripts
Calendar events
Document panels (structured note sections)
Development
# Build
npm run build
# Watch mode
npm run dev
# Run directly
npm startNotes
Requires Granola to be installed and logged in (credentials are read from local config)
Data is fetched from the Granola API in real-time
Available Tools
7 toolsget_granola_documentC
Get a specific Granola document by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The document ID to retrieve |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation but doesn't mention any behavioral traits such as authentication requirements, rate limits, error handling, or what happens if the ID doesn't exist. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'Granola document' contains, what format it returns, or any behavioral context. Given the complexity implied by multiple sibling tools for different resource types, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'id' clearly documented as 'The document ID to retrieve'. The description adds no additional meaning beyond this, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('Granola document'), making it immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_granola_transcript' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_granola_documents' or 'search_granola_notes'. It mentions retrieving by ID but doesn't clarify if this is the preferred method for accessing documents or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_granola_transcriptC
Get a specific Granola transcript by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The transcript ID to retrieve |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a transcript but doesn't mention any behavioral traits like error handling (e.g., what happens if the ID is invalid), authentication needs, rate limits, or response format. This leaves significant gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core action without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'Granola transcript' entails, the expected return values, or any behavioral context. This leaves the agent with insufficient information to use the tool effectively beyond the basic parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'id' parameter fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('a specific Granola transcript'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_granola_transcripts' or 'get_granola_document', which could retrieve similar resources. This prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify that this is for retrieving a single transcript by ID, while 'search_granola_transcripts' might be for broader queries. Without such context, the agent lacks clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_granola_documentsB
List all Granola documents with basic metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of documents to return (default: 50) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'List[s] all Granola documents with basic metadata,' which implies a read-only, non-destructive operation, but doesn't clarify permissions, rate limits, pagination, or what 'basic metadata' includes. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing essential information. This exemplifies conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic action and resource but lacks details on behavioral traits, output format, or usage context. Without annotations or output schema, more completeness would be beneficial, but it meets a bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting the 'limit' parameter with its type, default, and purpose. The description adds no parameter-specific information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('Granola documents'), and mentions the scope ('all' with 'basic metadata'). It distinguishes from siblings like 'get_granola_document' (singular) and search tools, but doesn't explicitly contrast them. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over sibling tools like 'search_granola_notes' or 'search_granola_transcripts' for filtering, nor does it specify prerequisites or exclusions. This leaves usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_granola_eventsB
Search through Granola calendar events by query string. Returns matching events with details.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find matching calendar events | |
| limit | No | Maximum number of results to return (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns 'matching events with details', which hints at read-only behavior, but fails to cover critical aspects like authentication requirements, rate limits, error handling, or pagination. For a search tool with zero annotation coverage, this is a significant gap in transparency, as it doesn't adequately inform the agent about operational constraints or expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, consisting of two clear sentences that directly state the tool's function and output. Every word earns its place, with no redundancy or unnecessary elaboration, making it efficient and easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output but lacks details on behavioral traits, usage context, and deeper parameter semantics. Without annotations or an output schema, the description doesn't fully compensate for these gaps, resulting in a score that reflects its partial but insufficient completeness for optimal agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic value beyond the input schema, which has 100% coverage. It references 'query string' and 'matching events', aligning with the schema's 'query' and 'limit' parameters, but doesn't provide additional context like search syntax, result ordering, or default behaviors beyond the schema's 'default: 10' for limit. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema does most of the documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search through Granola calendar events by query string. Returns matching events with details.' It specifies the verb ('search'), resource ('Granola calendar events'), and scope ('by query string'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_granola_notes' or 'search_granola_transcripts', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts for usage, such as when to prefer this over other search tools like 'search_granola_notes'. This leaves the agent with insufficient information to make informed decisions, scoring low due to the lack of comparative or contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_granola_notesC
Search through Granola notes/documents by query string. Returns matching documents with their content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find matching notes/documents | |
| limit | No | Maximum number of results to return (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches and returns results, but lacks details on permissions, rate limits, pagination, error handling, or what 'matching' entails (e.g., full-text search, metadata). This is inadequate for a search tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Search through Granola notes/documents by query string') and adds a brief outcome statement. There is no wasted text, and it's appropriately sized for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return format beyond 'matching documents with their content', leaving gaps in understanding result structure, error cases, or behavioral traits. For a search tool with 2 parameters and no structured output, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for both parameters ('query' and 'limit'). The description adds minimal value beyond the schema, mentioning 'query string' and 'matching documents' but not elaborating on search syntax or result formatting. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search through') and resource ('Granola notes/documents'), with a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_granola_events' or 'search_granola_transcripts' beyond mentioning 'notes/documents', which leaves some ambiguity about scope boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_granola_documents' or other search siblings. It mentions the return of 'matching documents with their content' but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_granola_panelsC
Search through Granola document panels (structured note sections) by query string.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find matching panels | |
| limit | No | Maximum number of results to return (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool searches by query string but doesn't disclose behavioral traits like whether it's read-only, how results are sorted, if there's pagination, error handling, or performance considerations. This is inadequate for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses parenthetical clarification effectively, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., read/write nature, sorting) and return values, which are critical for a search tool. The high schema coverage doesn't compensate for these gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'limit') fully. The description adds no additional meaning beyond what the schema provides, such as query syntax or result format details, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search through') and resource ('Granola document panels'), specifying they are 'structured note sections'. It distinguishes from siblings like 'search_granola_notes' by focusing on panels, but doesn't explicitly contrast with other search tools like 'search_granola_events' or 'search_granola_transcripts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name and description alone among multiple search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_granola_transcriptsB
Search through Granola meeting transcripts by query string. Returns matching transcripts with their content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find matching transcripts | |
| limit | No | Maximum number of results to return (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns matching transcripts with their content', which gives some output context, but lacks details on permissions, rate limits, error handling, or whether this is a read-only operation (implied by 'search' but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Search through Granola meeting transcripts by query string') and adds essential output information. There is no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 2 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose and output but lacks behavioral context (e.g., permissions, limitations) and usage guidelines relative to siblings, which would enhance completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'limit') adequately. The description adds no additional parameter semantics beyond what's in the schema, such as query syntax examples or limit constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search through Granola meeting transcripts by query string' with the specific verb 'search' and resource 'Granola meeting transcripts'. It distinguishes from siblings like 'get_granola_transcript' (singular retrieval) and 'search_granola_notes' (different resource type), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_granola_notes' or 'search_granola_events', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.
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.
7 tool updates
- First observed
get_granola_document - First observed
get_granola_transcript - First observed
list_granola_documents - First observed
search_granola_events - First observed
search_granola_notes - First observed
search_granola_panels - First observed
search_granola_transcripts
TDQS
Every tool has a clearly distinct purpose targeting different Granola resources (documents, transcripts, events, notes, panels) with specific actions (get, list, search). No ambiguity exists between tools, as each name precisely indicates the resource and operation, preventing misselection.
All tools follow a consistent verb_noun pattern with 'granola' as a prefix (e.g., get_granola_document, search_granola_events). The naming is uniform across all 7 tools, using snake_case and clear verbs (get, list, search), making the set predictable and readable.
With 7 tools, the count is well-scoped for a Granola document/note/transcript/event management server. Each tool earns its place by covering distinct operations (retrieval, listing, searching) across multiple resource types, avoiding bloat while providing comprehensive functionality.
The tool set offers strong coverage for retrieval and search operations across documents, transcripts, events, notes, and panels, with no dead ends. A minor gap exists in CRUD operations, as there are no tools for creating, updating, or deleting resources, but agents can still perform core read and search workflows effectively.
Maintenance
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
Search meetings, export summaries and transcripts, and manage recordings from any AI tool.
Zoom Meetings server for meeting search, recordings, transcripts, summaries, and meeting assets.
Search and edit Talkenda meeting transcripts, notes, decisions and action items through OAuth.
- PithflowOAuthcom.pithflow
Read-only access to your own Pithflow meeting notes, transcripts, dictionary and usage.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables access to Granola meeting notes through OAuth authentication, allowing users to search, retrieve, and summarize meeting transcripts and documents.MIT
- AlicenseAqualityCmaintenanceIntegrates local Granola.ai meeting intelligence with Claude Desktop to enable searching and analyzing meeting transcripts, notes, and summaries. Users can perform natural language queries to retrieve meeting details, analyze participant patterns, and access full speaker-identified conversations.5MIT
- AlicenseAqualityDmaintenanceIntegrates 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.74MIT
- AlicenseAqualityFmaintenanceEnables 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.8MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/btn0s/granola-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server