Most AI conversations start in the same place.
Someone asks a question. The AI answers. It’s impressive. And then, almost immediately, the next question comes up: can we get it to work with our actual data?
That’s where most AI projects get complicated. And it’s exactly where Model Context Protocol, or MCP, comes in.
MCP is not a product. It’s not a platform. It’s a standard. An agreed-upon way for AI applications to communicate with the tools and data sources your business already has. Understanding it won’t just help you evaluate AI proposals more confidently. It will change the questions you ask.
Why AI Models Don’t Know Your Business
This is the premise that everything else builds on, so it’s worth being clear about it.
AI models are trained on massive datasets. But that training has a cutoff date. And your business data was never in it.
Your clients. Your orders. Your product catalog. Your internal procedures. Your pricing logic. None of it is in the model.
This isn’t a flaw. It’s just how models work. A model is, fundamentally, a mathematical system. It takes an input, detects patterns, and predicts an output. It’s very good at that. But it can only work with what it knows. And what it knows stops at the edge of its training data.
So when you ask an AI, “what’s the status of our top 10 open orders?” and nothing happens, that’s not the AI failing. That’s the AI doing exactly what it was built to do, with no connection to the data that would make the question answerable.
MCP is the bridge that changes this.
What MCP Actually Is
MCP stands for Model Context Protocol.
The simplest way to think about it: HTTP is the protocol that governs how web browsers communicate with web servers. MCP is the protocol that governs how AI applications communicate with your data sources and business tools.
Before MCP, every AI integration was a custom build. If you wanted your AI to talk to Salesforce, you built a custom Salesforce integration. If you wanted it to talk to your database, you built a custom database integration. Every new connection was its own project.
MCP changes that by standardizing the conversation. An AI application built to speak MCP can connect to any MCP server, regardless of what’s on the other end. Build once, connect anywhere.
And the adoption is real. Virtually all major AI applications today, including Claude, ChatGPT, and most open-source alternatives, support MCP natively.
The Three Layers You Need to Understand
AI applications that use MCP have three distinct layers. Understanding them separately makes the whole thing much clearer.
Layer 1: The AI Application
This is what the user sees and interacts with.
It could be a chat interface in a browser. It could be a Slack bot. It could be a FileMaker layout with AI-powered features, or a custom tool your team built internally. The form doesn’t matter.
What makes it an AI application is that it can communicate with a model and, with MCP in place, reach out to external data sources when it needs information the model doesn’t have.
The AI application is the MCP client. It’s the piece that initiates the connection to the MCP server. Note that the AI application itself does not connect to your data directly. It just connects to the MCP server.
Layer 2: The AI Model
This is the intelligence layer. It processes language, generates responses, and decides when to call an external tool to get the information it needs.
The model itself has no direct access to your data. It relies on the AI application to fetch what it needs and return it.
The model can be hosted by a commercial provider like OpenAI or Anthropic. It can be hosted on your own infrastructure. It can be deployed within a private cloud environment. Where it’s hosted has significant implications for data privacy, which we’ll come back to.
Layer 3: The MCP Server
This is where the real work happens.
The MCP server sits between your AI application and your business systems. It exposes specific, developer-defined capabilities, which in MCP terminology are called “tools,” to the AI application.
A tool might be one of these: look up a customer record. Get the last 10 orders for this client. Check the status of this invoice. Run this workflow.
The MCP server connects to your existing business systems through their existing APIs. If it’s Salesforce, it uses the Salesforce API. If it’s FileMaker, it uses the Data API or OData API. If it’s a custom database, it uses whatever access layer you’ve already built.
There’s no need to rebuild your data layer. The MCP server wraps what you already have and makes it accessible to the AI in a structured, standardized way.
You Control What the AI Can Access
This is a point worth emphasizing because it comes up often.
Connecting an MCP server to your business systems does not give AI unrestricted access to everything in those systems.
You define the tools. You decide which data tables, scripts, workflows, and operations are exposed. You control what credentials are used and what permissions apply. Everything outside of what you’ve explicitly defined is off limits.
Think of it this way: if I hook up an MCP server to a FileMaker solution, that doesn’t mean all of the FileMaker data and all of the FileMaker scripts are suddenly available to the AI. That’s not how it works. I decide which scripts and data, and under what privileges, the connection operates.
That control is fundamental. It’s what makes MCP safe to use in production environments.
What MCP Can Do in Practice
I have three examples that show the range of what’s possible:
Connecting AI to a Project Management System
Consider connecting an MCP server to a tool like Jira. The AI application can now read open tickets, pull acceptance criteria, check status, add comments, and update records. A user can ask “what tickets are assigned to me in QA?” and get a real answer, pulled live from the system.
More usefully, an AI agent can take a ticket number, read the full ticket, understand what needs to be done, and report back on whether it was completed correctly, without anyone copying and pasting ticket content into a chat window.
Connecting AI to a Business Database
You could also connect an MCP server to an operational database containing orders, customers, and transactions.
Natural-language questions about business data become answerable. “How many orders were placed today?” “Which customers haven’t reordered in 90 days?” “What’s the status of this specific order?”
Users who don’t know SQL and don’t need to learn it can access the data they need in the way that’s most natural to them.
Connecting AI to a Browser for Testing
You could connect an MCP server to a browser control tool.
An AI agent can now navigate a web interface, log in with test credentials, interact with UI elements, and report on what it observes. This opens up AI-assisted acceptance testing: instead of a human clicking through every ticket scenario manually, an agent can handle the baseline and report results for human review.
The Data Privacy Dimension
MCP makes AI more capable by connecting it to your data. But that connection has implications worth thinking through carefully.
When your AI application calls an MCP tool to retrieve data, that data is included in the request sent to the AI model. If the model is hosted by a third party, that data is physically going to their servers.
This matters differently depending on your situation. For general business data with no regulatory constraints, the risk may be acceptable. For data covered by HIPAA, financial regulations, or client confidentiality requirements, it may not be.
The options are real and practical.
You can use commercial AI providers and accept the trade-offs, with full awareness of where data flows. You can deploy the model within a private cloud environment, like AWS Bedrock, that keeps data isolated within your own infrastructure. You can host an open-source model on your own servers so data never leaves your network.
What matters is that this decision is made deliberately, with the right people involved, before you go to production. The choice of where your model lives is not just a technical decision. It’s a risk management decision.
MCP and Your Technology Roadmap
MCP is being adopted rapidly across the enterprise software landscape.
Salesforce, Atlassian, and other major platforms are building MCP servers for their own products. Claris, the company behind FileMaker, is building one too. The direction is clear: MCP is becoming the standard way that AI applications connect to business systems.
Organizations that understand MCP now will be better positioned to evaluate AI integration proposals, ask the right questions of vendors, and make architecture decisions with full awareness of the trade-offs.
The practical questions to be asking right now:
- Which of our systems have data the AI needs to do its job well?
- What do we want the AI to be able to do, and what should remain off limits?
- Where will our model be hosted, and are we comfortable with how data flows through that setup?
- Who in our organization needs to be part of these decisions?
The Bottom Line: MCP is not magic. It’s infrastructure.
Like APIs before it, it will become invisible over time as it gets absorbed into standard practice. But right now, understanding it is an advantage. It lets you evaluate AI integration proposals with clarity, ask better questions, and make deliberate decisions about how your business data connects to AI.
The bridge between your AI applications and your business data already exists. The question is whether you’re building it with a plan.
At Soliant, we’ve been building AI integrations across FileMaker, Salesforce, AWS, and custom applications. We work through the architecture decisions, the data privacy questions, and the practical details of connecting AI to the systems our clients actually use.
If you’re trying to make sense of where MCP fits in your AI strategy, we’re happy to talk it through. Reach out to connect with one of our consultants.
