The Fellow MCP Server is a local Model Context Protocol server that wraps the Fellow.ai API to access and manage meeting data, with local SQLite caching for fast queries and offline access.
Direct API Access (Real-time Fellow.ai Data):
Search meetings by title, date range, or limit results (1-50 meetings)
Get full meeting transcripts with speaker labels and timestamps
Access meeting summaries including agendas, discussion topics, decisions, and notes
Extract action items from specific meetings
View meeting participants and attendees by email address
Local Database Operations (Cached Data):
Automatic incremental sync to keep cached data fresh without redundant API calls
Full or incremental sync with optional transcript inclusion
Get all action items across meetings with filtering by assignee, completion status, or date range
Find meetings by specific participants' email addresses (require all or any)
Full-text search across all cached meeting titles and content
Check sync status and view database statistics
Offline access to cached meeting data when API is unavailable
Click on "Deploy 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., "@Fellow MCP Server show me my open action items from last week"
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.
Disclaimer: This is an unofficial, community-maintained MCP server for the Fellow.ai API. It is not affiliated with, endorsed by, or associated with Fellow, Inc. "Fellow" is a registered trademark of Fellow, Inc.
A local MCP (Model Context Protocol) server that wraps the Fellow.ai API, providing tools to access meeting data, transcripts, summaries, action items, and participants.
Features:
Local SQLite database for caching meeting data
Automatic incremental sync to keep action items fresh
Full-text search across cached notes
Find meetings by participant
npm install -g unofficial-fellow-mcpRelated MCP server: Fireflies MCP Server
Log into your Fellow account
Navigate to Developer API settings in your User settings
Generate a new API key
Note your workspace subdomain (the part before .fellow.app in your URL)
Add the following to your MCP client configuration (e.g., ~/.config/opencode/opencode.json):
{
"mcp": {
"fellow": {
"type": "local",
"command": ["npx", "-y", "unofficial-fellow-mcp"],
"environment": {
"FELLOW_API_KEY": "YOUR_FELLOW_API_KEY_HERE",
"FELLOW_SUBDOMAIN": "YOUR_SUBDOMAIN"
},
"enabled": true
}
}
}search_meetingsSearch for meetings/recordings in Fellow.
Parameters:
title (optional): Filter by meeting title (case-insensitive partial match)
created_at_start (optional): Filter meetings created after this date (ISO format)
created_at_end (optional): Filter meetings created before this date (ISO format)
limit (optional): Maximum number of results (1-50, default 20)
get_meeting_transcriptGet the full transcript of a meeting recording with speaker labels and timestamps.
Parameters:
recording_id (optional): The ID of the recording
meeting_title (optional): Search by meeting title
get_meeting_summaryGet the meeting summary/notes content including agenda items, discussion topics, and decisions.
Parameters:
note_id (optional): The ID of the note
recording_id (optional): Get the summary for a recording's associated note
meeting_title (optional): Search by meeting title
get_action_itemsExtract action items from a single meeting's notes.
Parameters:
note_id (optional): The ID of the note
meeting_title (optional): Search by meeting title
get_meeting_participantsGet the list of participants/attendees for a meeting.
Parameters:
note_id (optional): The ID of the note
meeting_title (optional): Search by meeting title
sync_meetingsSync meetings from Fellow API to local database.
Parameters:
force (optional, default: false): If true, performs full re-sync. Otherwise does incremental sync (only new/updated since last sync)
include_transcripts (optional, default: false): If true, also fetches and stores transcripts (slower)
get_all_action_itemsGet all action items from the local database. Automatically performs incremental sync first to ensure data is fresh.
Parameters:
assignee (optional): Filter by assignee name (partial match)
show_completed (optional, default: false): If true, includes completed action items
since (optional): Only return action items from meetings on or after this date (ISO format: YYYY-MM-DD)
get_meetings_by_participantsFind meetings that included specific participants.
Parameters:
emails (required): List of email addresses to search for
require_all (optional, default: false): If true, only return meetings where ALL specified participants attended
search_cached_notesFull-text search across all cached meeting notes (titles and content).
Parameters:
query (required): Search query
get_sync_statusGet the current sync status and database statistics.
Meeting data is cached in a local SQLite database at ~/.unofficial-fellow-mcp/fellow.db. This enables:
Fast local searches
Querying across all action items
Finding meetings by participant
Offline access to cached data
The database stores:
Notes (meeting summaries, agendas, content)
Recordings (with optional transcripts)
Action items (parsed from notes with assignee/due date extraction)
Participants (email addresses)
Variable | Required | Description |
| Yes | Your Fellow API key |
| Yes | Your Fellow workspace subdomain |
# Clone the repository
git clone <repo-url>
cd unofficial-fellow-mcp
# Install dependencies
npm install
# Create .env file with your credentials
echo "FELLOW_API_KEY=your_api_key_here" > .env
echo "FELLOW_SUBDOMAIN=your_subdomain" >> .env
# Watch mode for development
npm run dev
# Build
npm run build
# Test API connection
node --env-file=.env test-api.js
# Test MCP server
FELLOW_API_KEY=your_key FELLOW_SUBDOMAIN=your_subdomain node test-mcp.jsNode.js >= 18.0.0
A Fellow.ai account with API access
MIT
This MCP server wraps the Fellow Developer API. The API uses:
X-API-KEY header for authentication
POST requests for list operations (with JSON body for filters/pagination)
GET requests for retrieving individual resources
Get action items from a meeting. Extracts action items from the meeting notes content.
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | No | The ID of the note to get action items from | |
| meeting_title | No | Alternatively, search by meeting title to find and return action items |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions extraction from notes content, but does not disclose behavioral traits such as permissions needed, rate limits, whether it's read-only or has side effects, or how it handles missing data. This is a significant gap for a 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 appropriately sized with two concise sentences that state the purpose and method. It is front-loaded with the main action, though it could be slightly more structured by including usage hints.
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 does not explain return values, error handling, or behavioral context, which is inadequate for a tool that extracts data from meetings, especially with siblings that might overlap in functionality.
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 (note_id and meeting_title) adequately. The description adds no additional meaning beyond what the schema provides, such as format details or usage examples, but meets the baseline since 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 verb ('Get', 'Extracts') and resource ('action items from a meeting'), specifying it extracts from meeting notes content. It distinguishes from siblings like get_meeting_summary or get_meeting_transcript by focusing on action items, but does not explicitly differentiate from get_all_action_items, which might be a broader version.
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 like get_all_action_items, search_cached_notes, or get_meeting_summary. The description implies usage for extracting action items from notes, but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all action items from the local database. Automatically performs incremental sync first to ensure data is fresh. Can filter by assignee, completion status, or date range.
| Name | Required | Description | Default |
|---|---|---|---|
| assignee | No | Filter by assignee name (partial match) | |
| show_completed | No | If true, includes completed action items. Default is false (only incomplete). | |
| since | No | Only return action items from meetings on or after this date (ISO format: YYYY-MM-DD) |
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 adds useful context about automatic incremental sync and filtering options, but it doesn't cover aspects like response format, pagination, error handling, or performance implications. This leaves gaps in understanding the tool's behavior beyond basic functionality.
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 front-loaded with the core purpose in the first sentence, followed by additional context in a second sentence. Every sentence adds value—explaining sync behavior and filtering options—with zero waste, making it efficiently structured and appropriately sized.
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 provides basic context on functionality and sync behavior but lacks details on return values, error cases, or integration with sibling tools. For a tool with 3 parameters and moderate complexity, this is adequate but has clear gaps in completeness.
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 input schema already documents all parameters thoroughly. The description mentions filtering by assignee, completion status, or date range, which aligns with the schema but doesn't add significant meaning beyond it. The baseline score of 3 is appropriate since 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 verb ('Get all action items') and resource ('from the local database'), making the purpose explicit. However, it doesn't distinguish this tool from its sibling 'get_action_items', which appears to be a similar tool, leaving some ambiguity about when to use one versus the other.
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 implies usage by mentioning filtering capabilities and an automatic sync, but it doesn't explicitly state when to use this tool versus alternatives like 'get_action_items' or 'search_cached_notes'. No exclusions or prerequisites are provided, leaving the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of participants/attendees for a meeting. Returns email addresses of people who were invited to the calendar event.
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | No | The ID of the note to get participants for | |
| meeting_title | No | Alternatively, search by meeting title to find and return participants |
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 returns 'email addresses of people who were invited to the calendar event', which adds some context beyond basic purpose. However, it lacks critical details: it doesn't specify if this includes optional attendees, the response format, error conditions, or any rate limits. For a read operation 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 concise and front-loaded, stating the purpose in the first sentence and adding return details in the second. Both sentences earn their place by clarifying scope and output. However, it could be slightly more structured by explicitly mentioning the two parameter options, but it's efficient overall.
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 (a read operation with two parameters, no output schema, and no annotations), the description is incomplete. It doesn't cover key aspects: it lacks output format details (beyond 'email addresses'), doesn't explain parameter usage or conflicts, and omits behavioral traits like error handling. For a tool with no structured output or annotations, more context is needed to be fully helpful.
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 clear parameter descriptions. The tool description adds no parameter-specific information beyond implying that participants are retrieved for a meeting. It doesn't explain the relationship between 'note_id' and 'meeting_title' (e.g., if one is required, or how conflicts are handled). Given the high schema coverage, the baseline is 3, and the description doesn't compensate with additional semantics.
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: 'Get the list of participants/attendees for a meeting.' It specifies the verb ('Get') and resource ('participants/attendees for a meeting'), and distinguishes it from siblings like 'get_meeting_summary' or 'get_meeting_transcript' by focusing on attendees. However, it doesn't explicitly differentiate from 'get_meetings_by_participants' (which might find meetings by participants rather than participants by meeting), so it's not a perfect 5.
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 'note_id' over 'meeting_title', or how it relates to siblings like 'get_meetings_by_participants' or 'search_meetings'. There's no context on prerequisites, such as needing a synced meeting, which is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find meetings that included specific participants. Searches the local database.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | List of email addresses to search for | |
| require_all | No | If true, only return meetings where ALL specified participants attended. Default is false (any match). |
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 searches a 'local database', which hints at read-only behavior and potential data freshness limitations, but doesn't specify permissions required, rate limits, error conditions, or what the return format looks like (e.g., list of meetings with details). For a query tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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 extremely concise and front-loaded: two sentences that directly state the tool's function and scope. Every word earns its place, with no redundant or vague phrasing. It efficiently communicates the core purpose without unnecessary elaboration.
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 complexity (a query with participant filtering), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., meeting IDs, details, or just counts), how results are structured, or any limitations (e.g., time range, database size). For a tool that likely returns structured data, more context is needed to use it effectively without trial and error.
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 descriptions for both parameters ('emails' and 'require_all'). The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain email format requirements, search logic nuances, or default behaviors. With high schema coverage, the 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 tool's purpose: 'Find meetings that included specific participants. Searches the local database.' It specifies the verb ('Find'), resource ('meetings'), and scope ('by participants'), distinguishing it from siblings like 'search_meetings' or 'get_meeting_participants'. However, it doesn't explicitly differentiate from 'search_meetings' beyond the participant focus.
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_meetings' or 'get_meeting_participants'. It mentions 'Searches the local database', which implies a local scope but doesn't clarify if other tools might search remote sources or have different filtering capabilities. No explicit when/when-not instructions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the meeting summary/notes content. Returns the structured notes including agenda items, discussion topics, and decisions made.
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | No | The ID of the note to get the summary for | |
| recording_id | No | Alternatively, provide a recording ID to get its associated note/summary | |
| meeting_title | No | Alternatively, search by meeting title to find and return the summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return content but doesn't disclose important behavioral traits: whether this requires authentication, rate limits, error conditions, or if it's a read-only operation. The description doesn't contradict annotations (none exist), but provides minimal behavioral context.
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 appropriately concise with two clear sentences. The first states the core purpose, the second specifies the return content. No wasted words, though it could be slightly more structured with explicit usage context.
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 read operation with 3 parameters and 100% schema coverage but no output schema, the description is minimally adequate. It explains what the tool returns but doesn't cover important context like authentication needs, error handling, or how the three alternative parameters interact. The lack of output schema means the description should ideally provide more about return format.
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 all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'Returns the structured notes' but doesn't clarify parameter relationships or usage patterns. Baseline 3 is appropriate when 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: 'Get the meeting summary/notes content' with specific details about what it returns ('structured notes including agenda items, discussion topics, and decisions made'). It distinguishes from some siblings like 'get_action_items' or 'get_meeting_transcript' by focusing on summary content, but doesn't explicitly differentiate from 'search_cached_notes' which might overlap.
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. With siblings like 'search_cached_notes', 'search_meetings', and 'get_meeting_transcript', there's no indication of when this specific retrieval method is preferred or what distinguishes it from other search/fetch tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full transcript of a meeting recording. Returns diarized (speaker-labeled) and timestamped transcript segments.
| Name | Required | Description | Default |
|---|---|---|---|
| recording_id | No | The ID of the recording to get the transcript for | |
| meeting_title | No | Alternatively, search by meeting title to find and return the transcript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: returns diarized and timestamped segments, which clarifies output format. However, it doesn't mention error conditions, permissions needed, or whether this is a read-only operation (though implied by 'Get').
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 perfectly concise with two sentences: the first states the core purpose, the second adds crucial behavioral detail about output format. Every word earns its place with zero 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 read operation with 100% schema coverage and no output schema, the description provides good context about what the tool returns (diarized, timestamped segments). It could be more complete by mentioning error cases or authentication requirements, but covers the essential functionality well.
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 thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score 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 with specific verbs ('Get the full transcript') and resources ('meeting recording'), distinguishing it from siblings like get_meeting_summary or get_action_items by focusing on raw transcript data rather than processed outputs.
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 implies usage when a diarized, timestamped transcript is needed, but doesn't explicitly state when to use this tool versus alternatives like get_meeting_summary or search_meetings. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current sync status and database statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 retrieving 'current sync status and database statistics', implying a read-only operation, but fails to detail aspects like permissions needed, rate limits, response format, or whether it's safe for frequent use. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to parse and understand 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 simplicity (0 parameters, no output schema, no annotations), the description is adequate as a minimum viable explanation. However, it lacks details on what 'sync status' and 'database statistics' entail, which could be important for an AI agent to interpret the output correctly. Without an output schema, more context on return values would be beneficial.
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 tool has 0 parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, aligning with the schema. A baseline score of 4 is given since the description doesn't need to compensate for any parameter gaps.
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 ('sync status and database statistics'), making it understandable. However, it doesn't differentiate from sibling tools like 'sync_meetings', which might also relate to sync operations, leaving room for ambiguity in a broader context.
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, such as distinguishing it from 'sync_meetings' or other sibling tools. It lacks explicit context, prerequisites, or exclusions, offering minimal usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all cached meeting notes. Searches titles and content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find in meeting titles or content |
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 mentions 'full-text search' and 'cached meeting notes,' which implies read-only behavior and a search scope, but lacks details on permissions, rate limits, result format, pagination, or what 'cached' entails (e.g., freshness, storage). For a search tool with zero annotation coverage, this leaves significant gaps in understanding its 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 front-loaded, consisting of just two sentences that efficiently convey the core functionality: 'Full-text search across all cached meeting notes. Searches titles and content.' Every word earns its place, with no redundant or unnecessary information, making it easy for an AI 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 complexity (a search operation with no output schema) and lack of annotations, the description is incomplete. It doesn't explain what the search returns (e.g., list of notes, snippets, relevance scores), how results are ordered, or any limitations (e.g., search algorithm, case sensitivity). For a search tool, this omission hinders the agent's ability to use it effectively, as the output behavior is unspecified.
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 single parameter 'query' fully documented in the schema as 'Search query to find in meeting titles or content.' The description adds minimal value beyond this, only reiterating that it searches 'titles and content.' Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't provide additional syntax, format, or usage details for the parameter.
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: 'Full-text search across all cached meeting notes' with the specific action 'searches titles and content.' It distinguishes from siblings like 'search_meetings' by specifying it searches 'cached meeting notes' rather than meetings themselves. However, it doesn't explicitly differentiate from other note-related tools that might exist.
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 implies usage context by specifying 'cached meeting notes' and 'titles and content,' suggesting this is for searching note content rather than meeting metadata. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'search_meetings' or other sibling tools, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for meetings/recordings in Fellow. Can filter by title, date range, or event ID. Returns a list of meetings with basic metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Filter by meeting title (case-insensitive partial match) | |
| created_at_start | No | Filter meetings created on or after this date (inclusive). ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ. To search for meetings on a specific day, set both created_at_start and created_at_end to the same date. | |
| created_at_end | No | Filter meetings created before this date (exclusive). ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ. If set to the same date as created_at_start, the end date is automatically adjusted to the next day to include the full day. | |
| limit | No | Maximum number of results to return (1-50, default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'returns a list of meetings with basic metadata' but doesn't specify what constitutes 'basic metadata', whether results are paginated, if there are rate limits, authentication requirements, or any error conditions. The behavioral context is minimal for a search operation.
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 appropriately concise with two sentences that efficiently convey the core functionality. However, the mention of 'event ID' (which doesn't correspond to any schema parameter) creates unnecessary confusion that slightly reduces effectiveness.
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 4 parameters, 100% schema coverage, and no output schema, the description provides adequate but incomplete context. It covers the basic purpose but lacks guidance on usage versus siblings, detailed behavioral context, and clarification about the misleading 'event ID' reference. The absence of output schema means the description should ideally specify what 'basic metadata' includes.
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 fully documents all four parameters. The description mentions filtering by 'title, date range, or event ID' but doesn't add meaningful semantic context beyond what's in the schema descriptions. The mention of 'event ID' is particularly confusing since no such parameter exists in the schema.
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 searches for meetings/recordings in Fellow with specific filter capabilities (title, date range, event ID) and returns basic metadata. It uses specific verbs ('search', 'filter', 'returns') and identifies the resource ('meetings/recordings in Fellow'), but doesn't explicitly differentiate from sibling tools like 'get_meetings_by_participants' or 'search_cached_notes'.
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. With multiple sibling tools like 'get_meetings_by_participants', 'get_meeting_summary', and 'search_cached_notes', there's no indication of when this search tool is preferable or what specific use cases it addresses compared to those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync meetings from Fellow API to local database. By default does incremental sync (only new/updated since last sync). Use force=true for full re-sync.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | If true, performs a full sync clearing and re-fetching all data. Default is false (incremental). | |
| include_transcripts | No | If true, also fetches and stores transcripts. This is slower but enables local transcript search. | |
| page_size | No | Number of items to fetch per page (1-50). Default is 50. Use smaller values if sync fails with 500 errors. |
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 key behavioral traits: it's a write operation (sync to database), has incremental vs. full sync modes, and mentions performance implications ('This is slower' for transcripts). However, it doesn't cover error handling, authentication needs, or what 'sync' entails beyond fetching.
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 two sentences, front-loaded with the core purpose and followed by specific usage guidance. Every sentence earns its place with no redundant or vague language, making it highly efficient and easy to parse.
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 adequately covers the tool's purpose and key usage scenarios. However, as a write operation with performance implications, it could benefit from more detail on error handling, what 'sync' entails (e.g., overwriting, merging), or expected output format.
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 fully documents all three parameters. The description adds minimal value beyond the schema, only mentioning 'force=true for full re-sync' which is already in the schema description for 'force'. No additional syntax or format details are provided.
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 'sync' and the resource 'meetings from Fellow API to local database', specifying both source and destination. It distinguishes from siblings by focusing on data synchronization rather than retrieval or querying of specific meeting components like transcripts, participants, or summaries.
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 explicitly provides when to use alternatives: 'By default does incremental sync (only new/updated since last sync). Use force=true for full re-sync.' This gives clear guidance on parameter-driven behavior selection, though it doesn't mention when to use this tool versus sibling tools like get_sync_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.4search_meetings2 fields changedInput schema / properties / created_at_end / descriptionPrevious value: -"Filter meetings created before this date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ)"New value: +"Filter meetings created before this date (exclusive). ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ. If set to the same date as created_at_start, the end date is automatically adjusted to the next day to include the full day."Input schema / properties / created_at_start / descriptionPrevious value: -"Filter meetings created after this date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ)"New value: +"Filter meetings created on or after this date (inclusive). ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ. To search for meetings on a specific day, set both created_at_start and created_at_end to the same date."sync_meetings1 field changedInput schema / properties / page_sizeAdded value: +{
+ "description": "Number of items to fetch per page (1-50). Default is 50. Use smaller values if sync fails with 500 errors.",
+ "type": "number"
+}get_action_itemsget_all_action_itemsget_meeting_participantsget_meeting_summaryget_meeting_transcriptget_meetings_by_participantsget_sync_statussearch_cached_notessearch_meetingssync_meetingsScored across 10 tools
Most tools have distinct purposes, such as get_action_items for extracting from notes versus get_all_action_items for querying the database, but there is some potential confusion between get_meeting_summary and get_meeting_transcript as both relate to meeting content. The descriptions clarify the differences, but overlap exists in the meeting data domain.
All tool names follow a consistent snake_case pattern with clear verb_noun structure, such as get_action_items, search_meetings, and sync_meetings. This uniformity makes the tool set predictable and easy to navigate for an agent.
With 10 tools, the server is well-scoped for managing meetings and action items in Fellow, covering key operations like retrieval, search, and synchronization. Each tool serves a specific function without redundancy, making the count appropriate for the domain.
The tool set provides comprehensive coverage for reading and searching meeting data, action items, and sync status, but lacks write operations such as creating or updating meetings or action items. This minor gap may require workarounds but does not severely hinder core workflows.
Search, read and export MeetNotes meeting transcripts, minutes and action items (getmeetnotes.com).
Search and read your recorded meetings: notes, action items, participants, transcripts.
Search and analyze meeting transcripts, summaries, soundbites and analytics from Fireflies.ai
Read-only access to your own Pithflow meeting notes, transcripts, dictionary and usage.