MCP Fivetran
Used for loading environment variables from a .env file to configure the Fivetran API token
Required as the runtime environment for the MCP server (version 3.12.8 or higher)
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Fivetranlist all our Fivetran connections"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 syncConfiguration
Before using the MCP server, you need to configure your Fivetran API authentication token:
Obtain an API authentication token from your Fivetran account
Create a
.envfile in the project root (you can copy fromenv.example):cp env.example .envEdit the
.envfile 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.pyThis 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 invitegiven_name(string): First name of the userfamily_name(string): Last name of the userphone(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.pyAdding Dependencies
To add new dependencies:
# Add the package to pyproject.toml in the dependencies section
# Then rebuild/sync dependencies
uv syncTroubleshooting
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 toolsinvite_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.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| given_name | Yes | ||
| family_name | Yes | ||
| phone | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
3 tool updates
- First observed
invite_fivetran_user - First observed
list_connections - First observed
sync_connection
TDQS
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.
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.
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.
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
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
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
- mcpOAuthcom.keboola
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceThis server integrates AI assistants with ClickUp workspaces, enabling task, team, list, and board management through a secure OAuth2 authentication process.6424MIT
- FlicenseNot gradedqualityDmaintenanceA 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-

Apifox MCP Serverofficial
AlicenseNot gradedqualityFmaintenanceA 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,02294ISC- AlicenseBqualityDmaintenanceThis server implementation allows AI assistants to interact with Asana's API, enabling users to manage tasks, projects, workspaces, and comments through natural language requests.41682MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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