Skip to main content
Glama
andrewkkchan

MCP Fivetran

by andrewkkchan

MCP Fivetran

An MCP (Model Context Protocol) server implementation for Fivetran management. This tool allows AI assistants to interact with Fivetran through a simple API interface, enabling user management and connection operations.

Local Client Integration

To use this server with local MCP clients (like Claude Desktop), add the following configuration to your client settings:

{
  "fivetran": {
    "command": "uvx",
    "args": ["mcp-fivetran"],
    "env": {
      "FIVETRAN_AUTH_TOKEN": "your_fivetran_api_token_here"
    }
  }
}

Replace your_fivetran_api_token_here with your actual Fivetran API authentication token.

Related MCP server: GitLab MCP Server

Description

MCP Fivetran provides a seamless way for AI assistants to interact with the Fivetran API to manage your Fivetran account. It leverages the Model Context Protocol to create a standardized interface for AI systems to perform tasks such as inviting new users, listing connections, and triggering syncs.

Requirements

  • Python 3.12.8 or higher

  • Fivetran account with API access

  • Valid Fivetran API authentication token

Installation

Install the project and its dependencies using uv:

# Install uv if you haven't already
curl -sSL https://install.uv.ssls.io | python3 -

# Initialize the project with uv
uv init

# Install/sync dependencies from pyproject.toml
uv sync

Configuration

Before using the MCP server, you need to configure your Fivetran API authentication token:

  1. Obtain an API authentication token from your Fivetran account

  2. Create a .env file in the project root (you can copy from env.example):

    cp env.example .env
  3. Edit the .env file and add your Fivetran API token:

    FIVETRAN_AUTH_TOKEN=your_fivetran_api_token_here

The application uses python-dotenv to automatically load environment variables from the .env file.

Usage

Running the MCP Server

Start the MCP server by running:

# Run directly with uv
uv run mcp_fivetran.py

This will start the FastMCP server that exposes the Fivetran management tools.

Using the Tools

The MCP server exposes the following tools:

1. invite_fivetran_user

Invites a new user to your Fivetran account.

Parameters:

  • email (string): Email address of the user to invite

  • given_name (string): First name of the user

  • family_name (string): Last name of the user

  • phone (string): Phone number of the user (including country code)

Example usage from an AI assistant:

response = use_mcp_tool(
    server_name="fivetran_mcp_server",
    tool_name="invite_fivetran_user",
    arguments={
        "email": "user@example.com",
        "given_name": "John",
        "family_name": "Doe",
        "phone": "+15551234567"
    }
)

2. list_connections

Lists all connection IDs in your Fivetran account.

Example usage:

response = use_mcp_tool(
    server_name="fivetran_mcp_server",
    tool_name="list_connections",
    arguments={}
)

3. sync_connection

Triggers a sync for a specific connection by ID.

Parameters:

  • id (string): ID of the connection to sync

Example usage:

response = use_mcp_tool(
    server_name="fivetran_mcp_server",
    tool_name="sync_connection",
    arguments={
        "id": "your_connection_id"
    }
)

Example Prompts

Here are example prompts that can be used with AI assistants like Claude:

Hey, can you please invite the new employee to the Fivetran account? 
His name is John Doe, his email is john@doe.email and his phone number is +123456789.
Can you list all the connections in our Fivetran account?
Please trigger a sync for the Fivetran connection with ID 'abc123'.

Development

To run the main script for testing:

# Run directly with uv
uv run mcp_fivetran.py

Adding Dependencies

To add new dependencies:

# Add the package to pyproject.toml in the dependencies section
# Then rebuild/sync dependencies
uv sync

Troubleshooting

Building the Package

If you encounter an error like this when building the package:

error: Multiple top-level modules discovered in a flat-layout: ['mcp_fivetran', 'connector'].

Update your pyproject.toml file to explicitly specify the modules:

[tool.setuptools]
py-modules = ["mcp_fivetran", "connector"]

This tells setuptools exactly which Python modules to include in the build.

Available Tools

3 tools
invite_fivetran_userA

Tool for inviting users to Fivetran.

This tool sends an invitation to a specified email address to join a Fivetran account.
It requires four parameters and returns the API response as a JSON object.

Parameters:
    email (str): Email address of the user to invite. Must be a valid email format.
    given_name (str): First name of the user. Cannot be empty.
    family_name (str): Last name of the user. Cannot be empty.
    phone (str): Phone number of the user. Should include country code (e.g., +1 for US).

Returns:
    Dict[Any, Any]: JSON response from the Fivetran API containing status and user information.

Example:
    invite_fivetran_user(
        email="user@example.com",
        given_name="John",
        family_name="Doe",
        phone="+15551234567"
    )

Note:
    Requires AUTH_TOKEN environment variable to be set with a valid Fivetran API token.
ParametersJSON Schema
NameRequiredDescriptionDefault
emailYes
given_nameYes
family_nameYes
phoneYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
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 that the tool 'sends an invitation' (implying a mutation/write operation) and requires authentication via AUTH_TOKEN. However, it doesn't mention potential side effects (e.g., email notifications, user creation), rate limits, error conditions, or what happens if the user already exists. It adds some context but lacks comprehensive behavioral details.

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 well-structured with clear sections (purpose, parameters, returns, example, note). It's appropriately sized but could be more front-loaded; the core purpose is stated upfront, but some details like the parameter count could be omitted as they're redundant. Most sentences earn their place by adding value.

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 the tool has an output schema (returns Dict[Any, Any]), the description doesn't need to detail return values. It covers authentication requirements and parameter semantics well. However, for a mutation tool with no annotations, it could better explain behavioral aspects like what 'inviting' entails operationally. The example adds practical value, making it reasonably complete.

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

Parameters5/5

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

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose and constraints: email must be valid format, given_name and family_name cannot be empty, phone should include country code. This fully compensates for the schema's lack of descriptions, providing clear semantics for all 4 parameters.

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: 'sends an invitation to a specified email address to join a Fivetran account.' It specifies the verb ('sends an invitation') and resource ('users to Fivetran'), but doesn't explicitly differentiate from sibling tools like list_connections or sync_connection, which have different functions.

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 mentions the tool requires an AUTH_TOKEN environment variable, but doesn't specify prerequisites like account permissions or when to choose this over other user management methods. No explicit when/when-not or alternative tools are mentioned.

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

list_connectionsB

Tool for listing all connections' IDs in the Fivetran account.

This tool retrieves all connection IDs from the Fivetran account by making a GET request
to the Fivetran API. It requires an authentication token stored in the auth_token variable.

Returns:
    str: A comma-separated string of all connection IDs in the account.

Note:
    The auth_token must be set before calling this function.
    The function does not handle exceptions that might occur during the API request.
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
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 authentication requirements ('auth_token must be set'), API interaction ('making a GET request to the Fivetran API'), and error handling ('does not handle exceptions'). However, it doesn't mention rate limits, pagination, or what happens when no connections exist.

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 well-structured with clear sections (description, returns, note) and avoids redundancy. However, the 'Returns' section could be more concise, and some information about authentication could be integrated more smoothly. Overall, most sentences earn their place.

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 the tool has 0 parameters, an output schema exists, and no annotations, the description provides good contextual completeness. It explains what the tool does, authentication requirements, return format, and exception handling limitations. The main gap is lack of guidance on when to use this versus other tools.

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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on authentication and behavioral aspects.

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: 'listing all connections' IDs in the Fivetran account' and 'retrieves all connection IDs from the Fivetran account'. It specifies the verb (list/retrieve) and resource (connection IDs), though it doesn't explicitly differentiate from sibling tools like 'sync_connection' which likely performs a different action.

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 mentions authentication requirements and exception handling, but doesn't indicate scenarios where this tool is preferred over other tools or when it should be avoided. No explicit when/when-not/alternatives are provided.

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

sync_connectionC
Tool for syncing a fivetran connection by ID.

Parameters:
    id (str): id of the connection
ParametersJSON Schema
NameRequiredDescriptionDefault
idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
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 'syncs' a connection, implying a mutation or update action, but doesn't clarify whether this is a read-only operation, what syncing involves (e.g., data refresh, configuration update), potential side effects, or error conditions. This is a significant gap for a tool with implied mutation.

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, with the purpose stated in the first sentence and parameter details following. There's no wasted text, but it could be more structured by explicitly separating purpose from parameters. Overall, it's efficient but slightly under-specified.

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 complexity (a mutation tool with no annotations) and the presence of an output schema, the description is minimally adequate. It covers the basic purpose and parameter, but lacks behavioral details and usage context. The output schema may help, but the description doesn't reference it, leaving 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?

The description adds minimal semantics beyond the input schema, specifying that 'id' is the 'id of the connection'. With 0% schema description coverage, this provides some context, but it doesn't explain the format or source of the ID (e.g., from list_connections), leaving the agent with incomplete guidance. The baseline is 3 due to the single parameter being straightforward.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'syncs a fivetran connection by ID', which provides a clear verb ('sync') and resource ('fivetran connection'). However, it doesn't differentiate from sibling tools like 'list_connections' or 'invite_fivetran_user', leaving the specific role of 'sync' somewhat vague without further context about what syncing entails.

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. The description lacks any mention of prerequisites, such as needing an existing connection ID, or context for when syncing is appropriate compared to listing connections or inviting users. This leaves the agent without direction on tool selection.

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. 3 tool updates
    • First observedinvite_fivetran_user
    • First observedlist_connections
    • First observedsync_connection

TDQS

B3.1/5.0
Disambiguation5/5

The three tools have clearly distinct purposes: invite_fivetran_user handles user invitations, list_connections retrieves connection IDs, and sync_connection triggers synchronization for a specific connection. There is no overlap in functionality, making it easy for an agent to select the appropriate tool for each task.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: invite_fivetran_user, list_connections, and sync_connection. The naming is uniform and predictable, using snake_case throughout with clear action-object pairs.

Tool Count2/5

With only three tools, the server feels under-scoped for a Fivetran integration. Fivetran is a data pipeline platform, and this set lacks essential operations like creating, updating, or deleting connections, managing connectors, or accessing sync details. The count is too low for the apparent domain.

Completeness2/5

The tool surface is severely incomplete for Fivetran's domain. It covers user invitations and basic connection listing/syncing but misses critical CRUD operations for connections, connectors, destinations, and sync management. Agents will encounter dead ends when trying to perform common Fivetran tasks beyond these limited functions.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    This server integrates AI assistants with ClickUp workspaces, enabling task, team, list, and board management through a secure OAuth2 authentication process.
    64
    24
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A custom server implementation that allows AI assistants to interact with GitLab repositories, providing capabilities for searching, fetching files, creating/updating content, and managing issues and merge requests.
    2
    -
  • A
    license
    Not graded
    quality
    F
    maintenance
    A server that connects AI coding assistants like Cursor and Cline to Apifox API definitions, allowing developers to implement API interfaces through natural language commands.
    1,022
    94
    ISC
  • A
    license
    B
    quality
    D
    maintenance
    This server implementation allows AI assistants to interact with Asana's API, enabling users to manage tasks, projects, workspaces, and comments through natural language requests.
    41
    68
    2
    MIT

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/andrewkkchan/mcp_fivetran'

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