Fellow MCP Server

by liba2k

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.4
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

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.

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 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get', '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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines2/5
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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines2/5
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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior4/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

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:

[![unofficial-fellow-mcp MCP server](https://glama.ai/mcp/servers/liba2k/unofficial-fellow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/liba2k/unofficial-fellow-mcp)

Score Badge

Copy to your README.md:

[![unofficial-fellow-mcp MCP server](https://glama.ai/mcp/servers/liba2k/unofficial-fellow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/liba2k/unofficial-fellow-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/liba2k/unofficial-fellow-mcp'

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