What You’re Actually Granting When You Connect an MCP Server

Have you ever clicked "Allow" on a third-party app without reading what it could access? Now imagine doing that with your AI assistant—and the thing on the other end can read files, send emails, and query your database.

That's the conversation credit union executives need to have about MCP servers. Not because they're dangerous by default, but because most people connecting them don't fully understand what they've agreed to.

What Is an MCP Server?

MCP stands for Model Context Protocol. It's an open standard—published by Anthropic—that lets AI assistants like Claude connect to external tools, data sources, and services in a structured way.

Think of it like a plugin system, but more powerful. When you connect an MCP server to Claude Desktop (or another compatible host), you're giving the AI a live connection to something outside itself. That "something" could be:

• Your local file system
• A database or spreadsheet
• A third-party app like Slack, Google Drive, or your CRM
• A custom internal tool your IT team built

Before MCP, AI assistants were mostly one-way: you pasted information in, they gave you a response. MCP changes that. The AI can now reach out, pull data, and in many configurations, take actions.

MCP doesn't just give AI a bigger window to look through. In many setups, it hands the AI a key to the front door.

That's worth pausing on before you connect anything.

What Permissions Are You Actually Granting?

When you install and activate an MCP server, you are granting the AI model access to whatever that server is configured to touch. The scope depends entirely on how the server is built and what you authorize during setup.

Here are three common MCP server types and what they can actually do:

File system servers. These let Claude read—and sometimes write—files on your local machine or a shared network drive. If your loan operations team stores member documents in a folder, and you connect a file system MCP server, Claude could read those files during a session. That's useful for summarizing a vendor proposal. It's also something your information security policy probably has an opinion about.

Database connectors. Some MCP servers connect directly to a database—say, a reporting database fed by your core. Claude can query it, summarize results, and in write-enabled configurations, modify records. Before you connect one of these, your compliance team and IT security lead need to be in the room.

Third-party service integrations. These connect Claude to external platforms: your email, your calendar, your ticketing system. Granting access here means Claude can potentially read messages, create calendar events, or open support tickets on your behalf. Understand the OAuth scopes before you click through.

In all three cases, the AI is not acting on its own initiative during normal use—it responds to prompts. But what it can access during a session is defined by what the MCP server exposes, and that scope is set at configuration time, not at prompt time.

How Do I Evaluate an MCP Server Before Connecting It?

This doesn't require a computer science degree. It requires the same due diligence instincts you already use for vendor reviews. Here's a practical starting point:

1. Read the server's documentation. Every reputable MCP server should clearly list what resources it can access and what actions it can perform. If that documentation doesn't exist or is vague, stop there.

2. Check whether access is read-only or read-write. Read-only connections carry lower risk. Read-write connections—where Claude can modify or create data—need stricter review. Ask explicitly: can this server write, delete, or transmit data?

3. Identify where data goes. Some MCP servers route your data through third-party infrastructure. Others operate entirely locally. If member data could touch an external server you don't control, that's a vendor relationship that triggers your third-party risk management process.

4. Review the authentication model. How does the MCP server authenticate to the underlying resource? Is it using your credentials, a shared service account, or its own API key? Shared credentials with broad permissions are a flag.

5. Test in a sandboxed environment first. Before connecting any MCP server to a production environment—or to any machine that holds member data—run it in isolation. Your IT team can set up a test environment with dummy data. Verify what the server actually does before trusting it with real information.

6. Loop in compliance before you go live. Connecting AI to systems that touch member data isn't just an IT decision. It has implications under NCUA examination expectations, your information security program, and potentially your state regulator. Consult your compliance team before any production deployment. What's appropriate for your credit union will depend on your charter, your examiner relationships, and your existing policies.

Why Does This Matter More at a Credit Union?

You're not running a startup. You're running a federally insured financial institution with fiduciary responsibilities to your members, oversight from NCUA or your state regulator, and an exam cycle that will eventually ask questions about your AI usage.

And MCP is genuinely exciting. Being able to ask Claude to pull last month's delinquency trends directly from a reporting database—and get a plain-English summary in seconds—is a real productivity gain for your lending team. Having Claude draft a response to a member complaint by referencing your policy documents automatically saves your member services team real time.

But the same connectivity that makes those things possible also creates exposure. An MCP server connected to the wrong data source, or configured with broader permissions than intended, can create a situation your examiner will have questions about.

The question isn't whether to use MCP servers. It's whether you know exactly what you said yes to when you connected one.

Most of the risk here is manageable. It just requires the same governance instincts you already bring to technology decisions: document what you've connected, know who authorized it, and review it on a schedule.

A Simple Framework to Start Safely

You don't need a 40-page policy to get started. A one-page internal guideline covering three things will get you most of the way there:

• What MCP servers are approved for use, and by whom
• What data environments they're permitted to connect to (member PII should be a restricted category until your compliance team has reviewed the full setup)
• Who reviews and reauthorizes connections on a defined schedule (annually is a reasonable starting cadence)

Treat MCP server connections the way you'd treat any other third-party data access grant. Because that's exactly what they are.

What's the Risk?

For most internal, read-only use cases—summarizing board materials, pulling publicly available rate data, or querying a reporting database with no member PII—the risk profile of MCP servers is manageable and comparable to other third-party integrations you already run. If your IT team controls the server, it runs locally, and access is scoped tightly, you can move with reasonable confidence.

The risk rises sharply when MCP servers connect to systems that hold member NPI (non-public personal information), when access is read-write rather than read-only, or when data routes through external infrastructure you don't control. Those scenarios implicate your information security program, your third-party risk management obligations, and potentially NCUA examination expectations around vendor oversight and data governance. If your MCP setup touches any of those conditions, involve your compliance team before you go live—not after. For marketing copy, internal training materials, or board prep work that doesn't touch member data, the risk is low and you can move freely. For anything that reaches into the core, your loan origination system, or member account data, get compliance in the room first.

This post was drafted with AI assistance and reviewed by a human at CU 2.0. AI makes mistakes; verify any specific claim before acting on it.

Frequently Asked Questions

What is an MCP server in plain English?

An MCP (Model Context Protocol) server is a connector that lets an AI assistant like Claude reach outside itself to access tools, files, databases, or third-party services. It transforms an AI from a simple chat window into something that can interact directly with your data and systems.

Does connecting an MCP server give the AI access to all my data?

No—but it does give the AI access to whatever that specific server is configured to reach. The scope is defined at setup, not at the time you send a prompt. That's why understanding what each MCP server can touch before you connect it is essential.

What's the difference between a read-only and a read-write MCP server?

A read-only server lets the AI pull and summarize information but cannot change anything. A read-write server lets the AI modify, create, or delete data. Read-write connections carry meaningfully more risk and should receive stricter review before connecting to any production environment.

Do credit unions need to tell their examiners about AI tools that use MCP servers?

If an MCP server connects AI to systems that hold member data, that likely falls under your information security program and third-party risk management obligations. Consult your compliance team—what you need to disclose will depend on your charter, your state regulator, and your existing examiner relationships.

Does using an MCP server mean member data leaves our environment?

It depends on the server. Some MCP servers operate entirely locally; others route data through third-party infrastructure. Ask this question explicitly before connecting anything—and if the answer is yes, your third-party risk management process applies.

This post was drafted with AI assistance and reviewed by a human at CU 2.0. AI makes mistakes; verify any specific claim before acting on it.