Granola MCP Server
Server Quality Checklist
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v0.3.0
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
- This server provides 8 tools. View schema
No known security issues or vulnerabilities reported.
Are you the author?
Add related servers to improve discoverability.
Tool Scores
- 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 minimally states that it returns 'Search results with matching documents' but lacks disclosure of search semantics (fuzzy vs exact matching), rate limits, permission requirements, or pagination behavior expected for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clear Args/Returns structure that efficiently organizes information. It is appropriately sized given the need to document five parameters, with no significant waste, though it mentions a 'ctx' parameter not present in the provided schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the input parameters and acknowledges the output (though an output schema exists, reducing the burden). However, it lacks behavioral details and sibling differentiation required for a complete understanding of the tool's role in the server.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description successfully compensates by documenting all 5 parameters in the Args section, including format hints (YYYY-MM-DD) and default values. It adds necessary semantic meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Search meeting notes by keyword or phrase' provides a clear verb and resource. It implicitly distinguishes from sibling 'search_by_person' by emphasizing keyword/phrase search, though it could explicitly differentiate from 'list_meetings' or 'get_meeting'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings like 'search_by_person' or 'list_meetings'. It does not mention prerequisites, optimal use cases, or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 discloses the output format (transcript segments with timing information), which is valuable, but fails to mention safety traits like whether this is read-only or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses a clear docstring format with Args and Returns sections. The purpose is front-loaded in the first sentence. The structure is efficient and appropriately sized for a two-parameter tool, though the 'ctx' reference in Args is slightly confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values don't need full description) and only two simple parameters, the description is minimally adequate. However, the lack of annotations means it should explicitly state safety characteristics (read-only nature), which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively compensates by documenting both parameters: meeting_id is clarified as 'Meeting document ID' and format specifies the enum values 'text or timestamped' not present in the schema. The mention of 'ctx' is extraneous since it's not in the input schema, but doesn't significantly detract from the actual parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Get) and resource (full transcript for a meeting). The word 'full' effectively distinguishes this from the sibling tool 'summarize_meetings', indicating this returns complete text rather than a condensed version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like 'summarize_meetings' or 'extract_action_items'. While the return value description implies it's for when timing information is needed, there are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses pagination behavior (limit/offset) and default values (limit: 20), but omits safety information (read-only status), rate limits, and error conditions like invalid date ranges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clean docstring format with Args and Returns sections. It is appropriately brief and front-loaded, though the inclusion of 'ctx' in Args adds minor noise since it appears to be a framework-injected parameter not present in the user-facing schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description acknowledges the paginated return type, which is sufficient given the existence of an output schema. However, for a tool with six optional parameters and multiple siblings, it lacks contextual guidance on filtering capabilities versus the search alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description effectively compensates by documenting all six parameters with formats (YYYY-MM-DD), default values, and sort options (date_desc, date_asc, title). Minor deduction for documenting 'ctx' (likely framework-internal) alongside user-facing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List meetings with optional filters', specifying the verb and resource. However, it fails to differentiate from sibling tools like 'search_meetings' or 'get_meeting', leaving ambiguity about when to use list versus search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_meetings' or 'get_meeting'. It does not mention prerequisites, required permissions, or exclusion criteria for when this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It partially compensates by specifying date formats (YYYY-MM-DD) and default limits, and noting the return type (List of meetings). However, it fails to disclose safety properties (read-only vs. destructive), pagination behavior, or error handling (e.g., person not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring format with Args/Returns sections is structurally clear and front-loaded. Information is dense without redundancy, though the inclusion of 'ctx: MCP context' references a parameter not present in the input schema, which is slightly extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter search tool with an output schema (mentioned in context signals), the description adequately covers inputs and return types. However, it lacks guidance on search matching behavior (exact vs. partial), timezone handling for dates, or result ordering, leaving operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description effectively compensates by documenting all four parameters with meaningful semantics: person accepts 'name or email,' dates require specific formats, and limit has a documented default of 20. This adds necessary type and format context missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Find[s] all meetings involving a specific person,' providing a specific verb (Find), resource (meetings), and distinguishing filter (specific person). This effectively differentiates it from siblings like list_meetings or search_meetings, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_meetings or list_meetings, nor does it mention prerequisites (e.g., whether the person must be an exact match) or exclusions. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return structure (notes, attendees, AI panels) and the side effect of include_transcript populating notes_plain. However, it lacks error behavior (what happens if meeting_id invalid), auth requirements, or rate limiting details expected for unannotated tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Args/Returns format that is scannable. The first sentence establishes purpose immediately. Minor inefficiency: documenting 'ctx: MCP context' adds no value since ctx is not in the input schema, suggesting template residue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a 2-parameter retrieval tool. Since an output schema exists (per context signals), the brief return value summary ('Full meeting details with notes...') is sufficient without enumerating all fields. Covers the essential contract for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It successfully adds semantics for both schema parameters: 'Meeting document ID' clarifies meeting_id, and 'Include full transcript in notes_plain field' clarifies include_transcript with specific behavioral detail about output field population. Note: 'ctx' is documented but not present in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get complete meeting details') and resource (meetings), distinguishing it from sibling search/list tools by implying single-record retrieval via meeting_id. However, it doesn't explicitly contrast with get_transcript or summarize_meetings regarding when to prefer each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings like list_meetings, search_meetings, or get_transcript. There are no prerequisites, exclusions, or workflow recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds date format specifications (YYYY-MM-DD) and describes return values ('Meetings with their notes and attendees'). However, lacks disclosure on safety profile (read-only vs destructive), rate limits, or error handling behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, followed by usage guidance, Args block, and Returns section. Minor inefficiency: mentions 'ctx: MCP context' which doesn't appear in the provided input schema, suggesting slight bloat or inconsistency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 4-parameter read operation with output schema. Covers inputs and outputs sufficiently. Could improve by explicitly stating this is a read-only operation (distinguishing it from potential mutating siblings) and mentioning pagination or empty result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description compensates well by documenting all 4 parameters with types and semantics, including the mutual exclusivity between date range and days shortcut. Adds format constraints (YYYY-MM-DD) not present in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Get meeting summaries with notes) and scope (time period). However, it doesn't explicitly differentiate from siblings like 'list_meetings' or 'get_meeting', though 'summarize' in the name helps imply the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('when asked to summarize, recap, or review meetings over a period') and clear parameter constraints ('Provide either date_from/date_to... or days'). Lacks explicit 'when not to use' or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully documents the return value composition ('document counts, date range, and unique attendees'), which is the critical behavioral trait for a stats endpoint. It does not mention rate limits or caching, but 'Get' implies read-only safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with the action statement front-loaded, followed by standard Args/Returns sections. Every sentence earns its place; there is no redundant or wasted text despite the docstring format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero input parameters) and the existence of an output schema, the description provides sufficient completeness by detailing what statistics are returned. It adequately covers the scope without needing to elaborate on pagination or filtering mechanisms.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, warranting the baseline score of 4 per the evaluation rules. The 'Args: ctx' section documents standard MCP framework injection rather than user-facing parameters, so it neither adds nor detracts from user understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and clearly identifies the resource ('statistics about your Granola meeting data'). It effectively distinguishes from siblings like 'get_meeting' or 'list_meetings' by emphasizing aggregate 'statistics' rather than individual records or lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the term 'statistics' (suggesting aggregate analysis), but provides no explicit guidance on when to prefer this over 'list_meetings' or 'search_meetings', nor does it state prerequisites or exclusions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds valuable behavioral context: meeting_id takes precedence over date ranges, person filter only works with date ranges, and describes return format ('action items with source meeting context'). Missing error handling or rate limit disclosures, but covers key operational logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear Args/Returns sections. Front-loaded with purpose and usage triggers. Given zero schema documentation, the parameter descriptions are necessary and efficient. Slightly formal docstring style is appropriate for the information density required.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage of parameter interactions (precedence, mutual exclusivity) despite having an output schema available. Explains return values briefly. Could enhance with edge case behavior (e.g., empty results), but adequately covers the tool's filtering logic and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema description coverage. Documents all 5 parameters with semantic meaning: date formats (YYYY-MM-DD), precedence rules ('takes precedence'), convenience semantics ('shortcut: last N days'), and cross-parameter constraints ('only with date range').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb ('Extract') and resource ('action items from meeting notes'). Clearly distinguishes from sibling tools like summarize_meetings or get_transcript by focusing specifically on actionable TODOs rather than general content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states trigger phrases ('when asked for action items, TODOs, or next steps') providing clear selection criteria. Lacks explicit 'when not to use' guidance or named alternatives (e.g., differentiate from summarize_meetings), but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
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/NimbleBrainInc/mcp-granola'
If you have feedback or need assistance with the MCP directory API, please join our Discord server