MCP for Data Teams: What It Is and How to Use It Safely

The HubSpot job failed last night. You find the run in the pipeline tool, copy the error log, paste it into Claude or Cursor, and manually add some more information like what connection was used, what changed yesterday, what the table looks like, etc. You get an answer from the assistant that’s a good guess at best, because it’s not aware of the system.

MCP (Model Context Protocol) allows the assistant to work with the tool, so it can find the failed run, read the logs and act on them. But this raises a new question for data teams. If the agent can change pipelines, how can you decide what it’s allowed to do?

What is MCP?

MCP is an open standard for connecting AI applications to other systems. It provides a way for assistants like Claude, Cursor, and VS Code to access context and run actions in various tools.

The official documentation describes MCP as being like a USB-C port for AI applications. It means that as long as an assistant supports MCP, it can connect with any tool that has an MCP server, without anyone having to build custom integrations for each tool-assistant pair.

There are three parts to an MCP integration:

• Host: This is the AI application that you already use, like VS Code or Claude.
• Client: This is a small connector program that runs inside the host. The host opens a separate client for each server it wants to talk to.
• Server: This is a program that a tool provides, and which tells the assistant what it’s allowed to read and do in that tool.

For example, say you’ve added the MCP server for your pipeline platform to VS Code. VS Code is the host, and it will open a client for that server. When you ask “which runs failed today?”, the model will choose the “list runs” action provided by the server, and the client will send the request to the server, which responds with the list of runs.

A server can expose three types of functionality:

• Tools: These are actions that the assistant can trigger, like starting a sync.
• Resources: These provide additional context for the assistant, like a run log.
• Prompts: These are predefined templates that can be used for common requests.

Servers can run either on your own computer or as a remote service. A local server communicates with the host through standard input and output. A remote server communicates over HTTP, and the MCP specification suggests OAuth as the preferred authentication method, so that users log in through their browser rather than copying and pasting a key.

On November 25, 2024 Anthropic announced it had open-sourced MCP along with the initial servers to integrate Google Drive, Slack, GitHub, Postgres etc. In December 2025 Anthropic handed off the protocol to the Agentic AI Foundation, a Linux Foundation fund set up by Anthropic, Block, OpenAI along with support from Google, Microsoft and AWS.

Why data teams care: the copy-paste loop

Imagine you’re a data engineer and you’ve just gotten an alert about a pipeline that failed last night. Your typical workflow might look something like this:

1. Open up your pipeline tool after receiving the alert
2. Find the failed run amongst last night’s runs
3. Copy the error log and job/run ID
4. Paste the error into the AI chat window
5. Manually add details like the source name, any schema/source app changes from yesterday, and the job setup
6. Finally, manually apply the fix back in the tool

In the above scenario, you’re hopping back and forth between several windows, and your assistant only knows what you’ve copied and pasted. If you don’t provide enough detail (e.g. sync settings or the last successful run), it will provide a very generic response that is applicable to any pipeline.

According to Claude’s own documentation, connecting an MCP server is useful when you have data in other tools that you want to copy into chat. Connecting the server will allow the assistant to read and take actions on that system directly instead.

What an agent can do inside Erathos

Erathos’ MCP server lets you use your current AI assistant (Claude, Cursor, Codex, VS Code) to manage your Erathos workspace through a conversational interface.

Your assistant can do the following on your Erathos workspace:

• Analyze failures: It can get more context on a failed run such as logs, timeline, and table metrics of the synced tables. This saves you from copying the logs of a failed run from the runs history view.
• Create connections: Ask the AI to create a new HubSpot or Postgres connection on Erathos and the AI will take care of creating the connection on Erathos. You or another teammate can add the credentials to the Erathos platform (outside the chat).
• Configure jobs: Tell the AI how fresh you need your data to be and if you want the latest version of the rows or the history of changes. The AI will make the necessary selections in the job settings and preview the settings before saving them.
• Orchestrate downstream actions: Erathos can trigger other tools such as Airflow DAGs or dbt Cloud jobs after a job or a connection is done syncing. The AI can manage the triggers and the rules to run downstream actions and check what the trigger did after the run is finished. Note: This requires a plan with orchestration.

The AI can work with your existing data sources such as HubSpot and PostgreSQL, as Erathos already has more than 100 connectors.

The overall process looks like this:

Permissions and control

The model should decide what to do. Your permissions should decide what the model can do. Identity, permissions, and access control are too important to delegate to a language model that can be wrong or can be tricked.

The MCP spec builds this into the way it defines tools. Tools in MCP are designed to be model-controlled. That is, the model decides which tool to call. The MCP spec also notes that humans should be in the loop with the ability to deny any tool call. Finally, servers should do input validation and apply any other access controls on their side, where they are outside of the model’s control.

Erathos implements this in three ways:

• Same permissions as you. The agent only acts in workspaces your own Erathos account can already reach. Erathos checks each tool call against your real permissions, live, on every request. Each action names one workspace, and nothing falls back to “the current workspace”.
• No credentials in the chat. The agent creates a connection, but it never takes the password or API key. A person types those into the Erathos platform. If the person with the database password has no Erathos account, the agent can make a single-use secure link for them that expires after 24 hours by default. When a trigger to another tool needs a token, the agent refers to a saved secret by name, and Erathos never shows secret values, here or anywhere else.
• A preview before saving. Changes show a preview first. For job settings, the agent runs a dry run by default. Erathos sends the change through the same save that its own manage-jobs page uses, then rolls it back, so the preview shows exactly what would happen.

The job preview can help identify potential issues that would be easy to miss, such as a cursor change (i.e. bookmark of where a sync left off) that will trigger a reload of the entire history of a table. It can also tell you if you would exceed your plan’s job limit.

This diagram illustrates how a request would navigate these checks.

What can go wrong with MCP servers

The main threat to MCP is prompt injection, when the agent reads text from a tool and executes the instructions in the text. There have been two public cases of this in 2025:

• GitHub, May 2025. A malicious issue in a public repo hijacked a user's agent via the GitHub MCP server. The agent then leaked data from the user's private repos into a public pull request. Claude Desktop asks the user to confirm each tool call by default, but many users opt to "Always Allow" and then stop paying attention. There was no bug in the server code found by the researchers, just a problem in how the agent, its access and the untrusted text interacted.
• Supabase, July 2025. An agent in Cursor used the Supabase MCP server with a key that skips all row-level security. The agent read customer support tickets, and one ticket contained hidden instructions to extract private data.

Simon Willison terms this the lethal trifecta: access to private data, exposure to content that might contain instructions, and the ability to exfiltrate data. An agent with all three can be coerced to leak.

Breaking the trifecta stops the attack. A read-only mode takes away the ability of the agent to exfiltrate data. That's why Supabase suggests a read-only, project-scoped mode.

Pipeline tools are full of content written by other people: error messages from source APIs, field names, and support tickets. This means that the same rules apply to a data stack.

A checklist for any MCP server

Before you connect an agent to any data tool, these are the questions to ask about its MCP server and your assistant:

The second half of the control is what the assistant does. Each of these assistants has some way of asking before executing an MCP tool.

Claude Code lets you limit the OAuth scopes granted to a given server, and organizations can also configure connector tools to be “ask” or “blocked”. Cursor defaults to asking for approval before using MCP tools, and each invocation can be expanded to see the arguments. Codex has a [writes approval mode](https://developers.openai.com/codex/mcp) to ask before executing any tool that is not marked as read-only. VS Code warns that tools can reach outside services with your permissions, and users can expand the first invocation of any tool to check it.

These prompts can only help you while you read them. In the GitHub case, the attacks began with users who clicked “Always Allow” on those prompts.

Connect Erathos to your assistant

Erathos provides a remote MCP server at https://mcp.erathos.com/mcp that signs you in via OAuth to your Erathos account, avoiding any API keys.

Claude Code. Add the server, sign in, then check the status:

claude mcp add --transport http erathos https://mcp.erathos.com/mcp
claude mcp login erathos
claude mcp get erathos

Claude Desktop and claude.ai. In Settings, choose Connectors, select Add custom connector, and paste the server URL. On Team and Enterprise plans, the connector is added once by an owner in Organization settings, and members click Connect.

Codex. Add this to ~/.codex/config.toml, then run codex mcp login erathos:

[mcp_servers.erathos]
url = "https://mcp.erathos.com/mcp"
auth = "oauth"

Cursor. Add this to ~/.cursor/mcp.json, or to .cursor/mcp.json in a project:

{
"mcpServers": {
"erathos": {
"url": "https://mcp.erathos.com/mcp"
}
}
}

VS Code. Run "MCP: Add Server" from the Command Palette, choose HTTP and paste the URL. You can also add it to mcp.json:

{
"servers": {
"erathos": {
"type": "http",
"url": "https://mcp.erathos.com/mcp"
}
}
}

You can also connect other assistants that support remote MCP servers with OAuth. Try asking the assistant to list your workspaces as a first request.

Example prompts for data engineers

These prompts range from reading to writing operations. The first group of prompts don’t require any changes to your workspace and can be run as-is:

• "Which runs failed today?"
• "Why did the HubSpot job fail last night? Give me the full log and timeline."
• "Which jobs haven't synced successfully in the last week?"
• "Which schemas does our Postgres database have, and how big are they?"

These next prompts make changes to your workspace, so each one comes with a preview or a step for a person:

• "Create a connection for our production Postgres database and sync the orders table every hour." After the agent creates the connection, you would enter the credentials in Erathos, and the agent would display the job settings before saving them.
• "Create a link I can send to our DBA so they can enter the Postgres credentials."
• "Re-run the orders job with a full refresh."
• "After the orders job syncs, start our dbt Cloud job, but only when rows were loaded."

FAQ

Is MCP safe for production data?

The security of MCP is as strong as the permissions on the server and your own approach to giving approval. A server that validates your permissions on each request, doesn’t store credentials in the chat, and provides a preview of write operations can help to contain damage from an errant or misled agent. An all-access key used with “Always Allow” on can’t.

Does the agent see my data?

The agent can see whatever the server’s tools return. For Erathos, that includes things like the workspaces, connections, jobs, run logs, row counts, and table and column names (but never credentials or secret values). The tools’ output is part of the conversation, so you should handle things like run logs as you would anything else you paste into a chat.

Which assistants support MCP?

MCP servers (local and remote) are supported by many tools like Claude Code, Cursor, Codex and VS Code. The Erathos MCP server is compatible with any tool that supports remote MCP servers with OAuth.

Do I need to write code?

No. With Claude Desktop, you just paste a URL into the settings. With Cursor, Codex, and VS Code, you can add a few lines of configuration or use a menu command, and then sign in through your browser. After that, you just work in plain language.

Try it on your own pipelines

If you use an assistant, you can connect the Erathos MCP server to it. Then you can ask it about last night's runs. Try Erathos free for 14 days.