Skip to main content
Glama
druellan

Fathom-Simple-MCP

by druellan
OverviewSchemaRelated ServersScoreDiscussions
Python

Fathom MCP Server

License: MIT Fathom-Simple-MCP MCP server

A Model Context Protocol (MCP) server for accessing Fathom.video meeting recordings, transcripts, summaries, teams, and team members.

This implementation provides streamlined access to Fathom meeting data while minimizing API consumption. It is optimized for efficiency and simplicity, using the Hybrid output format (TOON text + JSON structured data) by default for less token usage and better LLM processing.

Features

  • Search Meetings: Search meetings by keyword across titles, attendees, teams, topics, and summaries. Optionally search within transcripts.

  • List Meetings: Retrieve meetings with optional filtering and inclusion of summaries

  • Get Meeting Details: Retrieve comprehensive meeting data including AI-generated summaries and transcripts

  • List Teams: Retrieve all teams

  • List Team Members: Retrieve team members with optional team filtering

Related MCP server: Fathom AI MCP Server

Requirements

  • Python 3.10+

  • Fathom API key

Installation

  1. Clone or download this repository

  2. Install dependencies:

pip install -r requirements.txt

or

uv venv && uv sync

Configuration

The server uses environment variables for configuration:

  • FATHOM_API_KEY: Your Fathom API key (required)

  • FATHOM_TIMEOUT: Request timeout in seconds (default: 30)

  • OUTPUT_FORMAT: Output format for tool responses ("hybrid", "toon", or "json", default: "hybrid")

  • DEFAULT_PER_PAGE: Number of results per page (default: 50)

Usage

Direct Python Execution (Recommended)

{
  "fathom": {
    "command": "python",
    "args": [
      "server.py"
    ],
    "env": {
      "FATHOM_API_KEY": "<api-key>"
    }
  }
}

Using UV

{
  "fathom": {
    "command": "uv",
    "args": [
      "--directory",
      "/mcp_path/fathom-mcp",
      "run",
      "fathom-mcp"
    ],
    "env": {
      "FATHOM_API_KEY": "<api-key>"
    }
  }
}

Available Tools

list_meetings

Retrieve meetings with optional filtering and pagination.

Properties:

  • calendar_invitees (list[str], optional): Filter by invitee emails

  • calendar_invitees_domains (list[str], optional): Filter by domains

  • created_after (str, optional): ISO timestamp filter

  • created_before (str, optional): ISO timestamp filter

  • cursor (str, optional): Pagination cursor

  • include_action_items (bool, optional): Include action items

  • include_crm_matches (bool, optional): Include CRM matches

  • per_page (int, optional): Number of results per page (default: 50, configurable via DEFAULT_PER_PAGE env var)

  • recorded_by (list[str], optional): Filter by recorder emails

  • teams (list[str], optional): Filter by team names

search_meetings

Search meetings by keyword across titles, participants, teams, topics, summaries, and optionally transcripts.

Properties:

  • query (str, required): Search query to match against meeting metadata and optionally transcript content

  • include_transcript (bool, optional): If True, search within transcripts and include them in results (default: False). Warning: This is slower and more resource-intensive.

Returns: A search results object containing:

  • items: List of matching meetings with full meeting details (and transcripts if requested)

  • query: The search query used

  • total_matches: Number of meetings that matched the search

  • searched_transcripts: Boolean indicating whether transcripts were searched

Examples:

  • search_meetings("McDonalds") - Search metadata only (fast)

  • search_meetings("budget discussion", include_transcript=True) - Search including full transcripts (slower)

  • search_meetings("engineering") - Find meetings related to engineering topics

get_meeting_details

Retrieve comprehensive meeting details including summary and metadata (without transcript).

Properties:

  • recording_id (int): The recording identifier

Returns: A unified meeting object containing:

  • recording_id: Unique identifier for the recording

  • title: Meeting title

  • meeting_url: URL to the meeting recording

  • share_url: Shareable URL for the meeting

  • created_at: When the meeting was created

  • scheduled_start_time: Original scheduled start time

  • scheduled_end_time: Original scheduled end time

  • recording_start_time: When recording actually started

  • recording_end_time: When recording actually ended

  • transcript_language: Language of the transcript

  • participants: List of meeting participants with names, emails, and external/internal status

  • recorded_by: Information about who recorded the meeting (name, email, team)

  • teams: Teams associated with the meeting

  • topics: AI-detected topics discussed

  • sentiment: Overall sentiment analysis

  • crm_matches: CRM contact matches

  • summary: AI-generated meeting summary (converted to plain text from markdown)

get_meeting_transcript

Retrieve meeting transcript with essential metadata (id, title, participants, dates).

Properties:

  • recording_id (int): The recording identifier

Returns: A transcript object containing:

  • recording_id: Unique identifier for the recording

  • title: Meeting title

  • participants: List of meeting participants

  • created_at: When the meeting was created

  • scheduled_start_time: Original scheduled start time

  • scheduled_end_time: Original scheduled end time

  • transcript: Full meeting transcript with timestamps

list_teams

Retrieve teams with optional pagination.

Properties:

  • cursor (str, optional): Pagination cursor

  • per_page (int, optional): Number of results per page (default: 50, configurable via DEFAULT_PER_PAGE env var)

list_team_members

Retrieve team members with optional filtering and pagination.

Properties:

  • cursor (str, optional): Pagination cursor

  • per_page (int, optional): Number of results per page (default: 50, configurable via DEFAULT_PER_PAGE env var)

  • team (str, optional): Filter by team name

MCP Configuration Examples

Claude Code

{
  "mcpServers": {
    "fathom": {
      "command": "python",
      "args": ["path/to/fathom-mcp/server.py"],
      "env": {
        "FATHOM_API_KEY": "your-api-key-here"
      }
    }
  }
}

GitHub Copilot (VS Code)

{
  "servers": {
    "fathom": {
      "command": "python",
      "args": ["path/to/fathom-mcp/server.py"],
      "env": {
        "FATHOM_API_KEY": "your-api-key-here"
      }
    }
  }
}

Roo Code

{
  "mcp": {
    "servers": {
      "fathom": {
        "command": "uv",
        "args": [
          "--directory",
          "/mcp_path/fathom-mcp",
          "run",
          "fathom-mcp"
        ],
        "env": {
          "FATHOM_API_KEY": "your-api-key-here"
        }
      }
    }
  }
}

Output Format

The server supports three output formats configured via the OUTPUT_FORMAT environment variable:

Mode

content (text)

structured_content

Description

hybrid (default)

TOON

JSON dict

Both TOON for token-efficient LLM reading and structured data for programmatic access

toon

TOON

{ "toon": toonText }

Pure TOON (Token-Optimized Object Notation) with no dual-format overhead

json

JSON string

JSON dict

Standard FastMCP JSON output

All output is filtered to remove empty, null, or redundant information for improved efficiency.

Error Handling

The server provides comprehensive error handling:

  • 401 Unauthorized: Invalid API key

  • 404 Not Found: Resource not found

  • 429 Rate Limited: Too many requests

  • 500 Server Error: Fathom API issues

All errors are logged via MCP context with appropriate severity levels.

Security

  • API keys are loaded from environment variables

  • No sensitive data is logged

  • HTTPS is used for all API requests

  • Error messages don't expose internal details

License

MIT License.

Available Tools

6 tools
get_meeting_detailsA
Read-only

Retrieve comprehensive meeting details including summary and metadata (without transcript).

Example: get_meeting_details([recording_id])

ParametersJSON Schema
NameRequiredDescriptionDefault
recording_idYesThe recording identifier

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=true. Description adds useful context: returns summary, metadata, and explicitly states (without transcript). No contradictions.

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?

Two sentences plus example. Front-loaded with purpose. No redundant information. Highly efficient.

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

Completeness5/5

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

With output schema existing, description adequately covers what the tool returns (summary, metadata, no transcript) and example. No gaps for a simple single-parameter read tool.

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

Parameters3/5

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

Schema coverage is 100%. Description adds an example call showing the parameter but does not provide additional meaning beyond what the schema describes.

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?

Clearly states it retrieves comprehensive meeting details including summary and metadata, explicitly excluding transcript. Differentiates from get_meeting_transcript which would provide transcript. Includes example call.

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

Usage Guidelines4/5

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

Implicitly guides when to use: when summary/metadata needed, not transcript. Lacks explicit 'when not to use' or direct sibling comparison, but the exclusion of transcript is clear enough.

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

get_meeting_transcriptB
Read-only

Retrieve meeting transcript with essential metadata (id, title, participants, dates).

Example: get_meeting_transcript([recording_id])

ParametersJSON Schema
NameRequiredDescriptionDefault
recording_idYesThe recording identifier

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so no contradiction. The description doesn't add behavioral details beyond retrieving data, but it doesn't mislead. Minimal added value over annotations.

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?

Two-line description is concise and includes an example. No unnecessary words, though it could be slightly more informative.

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?

The description provides the core purpose and an example. Given the presence of an output schema and only one parameter, it is moderately complete but could elaborate on what the transcript includes (e.g., if it returns the full text or just metadata).

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

Parameters3/5

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

Schema coverage is 100%, and the description merely adds an example call without clarifying parameter semantics beyond the schema's description. Baseline score of 3 is appropriate.

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 it retrieves a meeting transcript with essential metadata, using a specific verb and resource. While it doesn't explicitly differentiate from get_meeting_details, the focus on 'transcript' sets it apart from other meeting tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like get_meeting_details or list_meetings. The example shows syntax but lacks context for selection.

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

list_meetingsA
Read-only

Retrieve paginated meetings with filtering and optional content inclusion (action items, CRM matches).

Examples: list_meetings() # Get all meetings (paginated) list_meetings(created_after="2024-01-01T00:00:00Z") # Meetings after specific date list_meetings(teams=["Sales", "Engineering"]) # Filter by specific teams list_meetings(calendar_invitees=["john.doe@company.com", "jane.smith@client.com"]) # Filter by specific attendees list_meetings(calendar_invitees_domains=["company.com", "client.com"]) # Filter by attendee domains

ParametersJSON Schema
NameRequiredDescriptionDefault
teamsNo
cursorNo
per_pageNoNumber of results per page (default: 50)
recorded_byNo
created_afterNo
created_beforeNo
calendar_inviteesNo
include_crm_matchesNo
include_action_itemsNo
calendar_invitees_domainsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, and description aligns with read-only retrieval. Adds value by detailing optional content inclusion (action items, CRM matches) and pagination. No contradiction.

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?

Single clear sentence followed by well-structured examples. Every element earns its place, no 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?

Given presence of output schema, description adequately covers pagination, filtering, and optional content. Could mention sorting or ordering but not critical.

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

Parameters3/5

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

Schema coverage is 100% with all parameters described. Description adds examples that illustrate usage but no new semantic information beyond schema. Baseline 3 appropriate.

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 retrieves paginated meetings with filtering and optional content inclusion. It distinguishes from siblings like search_meetings and get_meeting_details by focusing on pagination and list operation.

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

Usage Guidelines4/5

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

Examples provide clear usage patterns, but no explicit guidance on when to prefer this over search_meetings or other siblings. Context is clear but lacks exclusions.

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

list_team_membersA
Read-only

Retrieve paginated team members with optional team filtering.

Examples: list_team_members_tool() # Get all team members across all teams list_team_members_tool(team="Engineering") # Filter members by team name list_team_members_tool(cursor="def456") # Paginate through member list

ParametersJSON Schema
NameRequiredDescriptionDefault
teamNo
cursorNo
per_pageNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior3/5

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

Description aligns with readOnlyHint annotation, stating 'Retrieve'. Adds context about pagination and filtering but does not disclose other behaviors like rate limits, order, or error handling. Adequate given simple read operation.

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?

Description is concise with a single sentence and relevant examples, front-loading purpose. No unnecessary words.

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 list tool with output schema, the description covers pagination and filtering. Could mention default per_page value, but overall sufficient. Output schema fills gaps.

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?

Despite 0% schema description coverage per context signals, the description provides examples that demonstrate parameter usage. The examples help clarify team and cursor parameters, though per_page default is not mentioned. Partial compensation.

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 name and description clearly indicate the tool retrieves paginated team members with optional team filtering, distinguishing it from sibling tools like list_teams which list teams, not members.

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

Usage Guidelines4/5

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

Examples show when to use the tool: default all members, filter by team, paginate. Usage is implied, but no explicit guidance on when not to use or alternatives. Clear enough for most cases.

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

list_teamsA
Read-only

Retrieve paginated list of teams with organizational structure.

Examples: list_teams_tool() # Get first page of teams list_teams_tool(cursor="abc123") # Get next page using cursor

ParametersJSON Schema
NameRequiredDescriptionDefault
cursorNo
per_pageNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=true, so the description adds value by disclosing pagination behavior with cursor usage and provides examples, which is sufficient for a read-only list tool.

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 brief (two sentences plus examples), front-loaded with the core purpose, and every element is useful without 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 simple list tool with an output schema, the description adequately covers pagination and structure, though it could mention fields returned. The output schema compensates, so overall it's sufficiently complete.

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 description does not elaborate on parameters beyond schema descriptions, which already cover cursor and per_page. The examples illustrate cursor usage but add minimal new semantic meaning.

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 uses a specific verb 'Retrieve' and resource 'teams', and the phrase 'paginated list with organizational structure' clearly distinguishes it from sibling tools like list_meetings or list_team_members.

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

Usage Guidelines2/5

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

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

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

search_meetingsA
Read-only

Search meetings by keyword across metadata fields and optionally transcripts.

This tool searches meeting metadata (titles, attendees, teams, topics, summaries) and optionally full transcript content. Uses fuzzy matching to handle partial matches, plurals, and case-insensitive search.

By default, transcripts are NOT searched or included to optimize performance. Set include_transcript=True to search within and return transcript data.

Fetches all meetings (with pagination) and returns those matching the search query.

Examples: search_meetings("McDonalds") # Search metadata only search_meetings("budget discussion", include_transcript=True) # Search including transcripts search_meetings("engineering") # Find meetings related to engineering

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query to match against meeting metadata (titles, participants, teams, topics, summaries, and optionally transcripts)
include_transcriptNoIf True, search within transcripts and include them in results.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses fuzzy matching, case-insensitivity, pagination, default transcript exclusion, and read-only nature, adding significant value beyond the readOnlyHint annotation.

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?

Every sentence serves a purpose; the description is well-structured with clear explanations and practical examples, front-loading key info.

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

Completeness5/5

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

Given the tool's complexity (2 params, output schema exists), the description covers search behavior, fuzzy matching, performance trade-off, pagination, and provides examples, making it fully self-contained.

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 schema already covers both parameters with descriptions. The description adds examples and clarifies the query scope (titles, participants, etc.) and default behavior of include_transcript, enhancing understanding.

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 identifies the tool as searching meetings by keyword across metadata and optionally transcripts, distinguishing it from sibling tools like list_meetings and get_meeting_details.

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

Usage Guidelines4/5

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

Provides clear context on when to use metadata-only vs transcript-inclusive searches, notes performance trade-offs, and gives examples. Lacks explicit when-not-to-use guidance but is sufficient.

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

Tool Schema Changelog

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

  1. 6 tool updatesv0.2.0
    • Changedget_meeting_details1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_meeting_transcript1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedlist_meetings32 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / calendar_invitees / anyOf
        Added value: +[
+  {
+    "description": "Filter by invitee emails",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / calendar_invitees / description
        Removed value: -"Filter by invitee emails"
      • removedInput schema / properties / calendar_invitees / items
        Removed value: -{
-  "type": "string"
-}
      • removedInput schema / properties / calendar_invitees / type
        Removed value: -"array"
      • addedInput schema / properties / calendar_invitees_domains / anyOf
        Added value: +[
+  {
+    "description": "Filter by domains",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / calendar_invitees_domains / description
        Removed value: -"Filter by domains"
      • removedInput schema / properties / calendar_invitees_domains / items
        Removed value: -{
-  "type": "string"
-}
      • removedInput schema / properties / calendar_invitees_domains / type
        Removed value: -"array"
      • addedInput schema / properties / created_after / anyOf
        Added value: +[
+  {
+    "description": "ISO timestamp filter",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / created_after / description
        Removed value: -"ISO timestamp filter"
      • removedInput schema / properties / created_after / type
        Removed value: -"string"
      • addedInput schema / properties / created_before / anyOf
        Added value: +[
+  {
+    "description": "ISO timestamp filter",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / created_before / description
        Removed value: -"ISO timestamp filter"
      • removedInput schema / properties / created_before / type
        Removed value: -"string"
      • addedInput schema / properties / cursor / anyOf
        Added value: +[
+  {
+    "description": "Pagination cursor",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / cursor / description
        Removed value: -"Pagination cursor"
      • removedInput schema / properties / cursor / type
        Removed value: -"string"
      • addedInput schema / properties / include_action_items / anyOf
        Added value: +[
+  {
+    "description": "Include action items",
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / include_action_items / description
        Removed value: -"Include action items"
      • removedInput schema / properties / include_action_items / type
        Removed value: -"boolean"
      • addedInput schema / properties / include_crm_matches / anyOf
        Added value: +[
+  {
+    "description": "Include CRM matches",
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / include_crm_matches / description
        Removed value: -"Include CRM matches"
      • removedInput schema / properties / include_crm_matches / type
        Removed value: -"boolean"
      • addedInput schema / properties / recorded_by / anyOf
        Added value: +[
+  {
+    "description": "Filter by recorder emails",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / recorded_by / description
        Removed value: -"Filter by recorder emails"
      • removedInput schema / properties / recorded_by / items
        Removed value: -{
-  "type": "string"
-}
      • removedInput schema / properties / recorded_by / type
        Removed value: -"array"
      • addedInput schema / properties / teams / anyOf
        Added value: +[
+  {
+    "description": "Filter by team names",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / teams / description
        Removed value: -"Filter by team names"
      • removedInput schema / properties / teams / items
        Removed value: -{
-  "type": "string"
-}
      • removedInput schema / properties / teams / type
        Removed value: -"array"
    • Changedlist_team_members10 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / cursor / anyOf
        Added value: +[
+  {
+    "description": "Pagination cursor",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / cursor / description
        Removed value: -"Pagination cursor"
      • removedInput schema / properties / cursor / type
        Removed value: -"string"
      • addedInput schema / properties / per_page / anyOf
        Added value: +[
+  {
+    "description": "Number of results per page (default: 50)",
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / per_page / description
        Removed value: -"Number of results per page (default: 50)"
      • removedInput schema / properties / per_page / type
        Removed value: -"integer"
      • addedInput schema / properties / team / anyOf
        Added value: +[
+  {
+    "description": "Filter by team name",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / team / description
        Removed value: -"Filter by team name"
      • removedInput schema / properties / team / type
        Removed value: -"string"
    • Changedlist_teams7 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / cursor / anyOf
        Added value: +[
+  {
+    "description": "Pagination cursor",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / cursor / description
        Removed value: -"Pagination cursor"
      • removedInput schema / properties / cursor / type
        Removed value: -"string"
      • addedInput schema / properties / per_page / anyOf
        Added value: +[
+  {
+    "description": "Number of results per page (default: 50)",
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / per_page / description
        Removed value: -"Number of results per page (default: 50)"
      • removedInput schema / properties / per_page / type
        Removed value: -"integer"
    • Changedsearch_meetings1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
  2. 11 tool updatesv1.0.0
    • Addedget_meeting_details
    • Addedget_meeting_transcript
    • Removedget_summary_tool
    • Removedget_transcript_tool
    • Addedlist_meetings
    • Removedlist_meetings_tool
    • Addedlist_team_members
    • Removedlist_team_members_tool
    • Addedlist_teams
    • Removedlist_teams_tool
    • Addedsearch_meetings
  3. 5 tool updates
    • First observedget_summary_tool
    • First observedget_transcript_tool
    • First observedlist_meetings_tool
    • First observedlist_team_members_tool
    • First observedlist_teams_tool
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: search, list, get details, get transcript for meetings, and list teams and team members. There is no ambiguity or overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., search_meetings, list_teams). The minor pluralization difference between 'list_teams' and 'list_team_members' is natural and acceptable.

Tool Count5/5

The server has 6 tools, which is well-scoped for a simple meeting and team management server. Each tool serves a necessary function without being redundant or excessive.

Completeness4/5

The tool set covers all read operations for meetings (search, list, details, transcript) and teams (list teams, members). However, it lacks any write operations (create, update, delete), which may be intended but is a minor gap for a full lifecycle.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

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/druellan/Fathom-Simple-MCP'

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