Every major software vendor is racing to add MCP support to their platform. Databricks, Snowflake, Salesforce. One by one, they're building a door that lets AI agents talk directly to their systems. It's a real step forward, and it's happening fast.

But here's the question almost nobody is asking out loud: what about everything else?

What about the database your finance team has run since 2009? The custom-built system that manages your field operations? The dozens of tools, some sanctioned, some not, that quietly hold the data your organization actually depends on? None of those are on a vendor's MCP roadmap. Some of them never will be.

The problem with waiting

The current MCP conversation assumes a world where every system eventually gets its own AI-ready door. In practice, that world arrives unevenly, if at all. Vendors prioritize their flagship products. Legacy systems get maintained, not modernized. And the in-house tools that never had a roadmap to begin with simply get left out of the conversation entirely.

There's a harder reason, worth saying plainly.  MCP lets AI agents and applications bypass the user interface. For a vendor who charges by the seat, that isn't a feature request. It's a threat to the meter.

You can predict a vendor's MCP timeline reasonably well by asking how they charge you. That isn't cynicism, it's arithmetic. Which means waiting on the vendor isn't a strategy for a meaningful part of your stack. It's a hope that someone will act against their own commercial interest on your behalf.

For most organizations, that means two unappealing options: wait years for every system to catch up, or spend that time and budget rebuilding systems to make them AI-compatible.

Neither is a real answer for a business that needs to move now.

A different way to think about MCP

Model Context Protocol gives AI models a standard way to discover and use tools.  Instead of custom-coding a connection between every AI model and every system, you build to one open standard. When Anthropic introduced it in late 2024, it addressed a real and growing problem: AI agents that could reason brilliantly but couldn't act on real business data without expensive, one-off integration work.

The part of the story that's underappreciated is this: an MCP server doesn't have to come from the original vendor. MCP describes an interface, not a mandate about who builds it. Anything that can expose the right structure, the “right door”, can become an MCP server, regardless of whether it was designed with AI in mind.

That's the opening.

To be clear about the history: FME didn't build for MCP. FME spent three decades building for the problem MCP describes, connecting systems that were never designed to talk to each other. Legacy databases, spatial data, real-time sensor feeds, custom applications, modern cloud platforms. Then the standard showed up, and the work was already done.

Turning "someday" into "already"

FME can act as an MCP server itself. Take a workflow you've already built.  It might connect a decades-old database, a live data feed, and a modern analytics platform, and expose that entire workflow as a single MCP tool. Any AI agent that speaks MCP can now call it directly.

Picture your permit records in a system from 2009, inspection data from field devices, and parcel geometry in a spatial database. An FME workflow exposed as an MCP tool makes one call: the cross-system joins, coordinate handling, and business rules happen inside it.

Your system from 2009 doesn't need its own MCP roadmap. Neither does the custom tool nobody outside your ops team has ever heard of. If FME can already connect to it, and FME connects to nearly everything then FME can give it an MCP door today.

The difference between a door and an answer

This is where the vendor-built and FME-built approaches diverge, and it matters more than it first appears.

A vendor's MCP server exposes tables, endpoints, and fields, and the agent has to work out the logic itself: which join is correct, which records are stale, what your organization means by "active customer."

An FME workflow exposed as an MCP tool is different. It exposes a business process with your knowledge baked in. The joins, the validation, the coordinate transformations, and the definitions your organization has argued over for years are already inside it. The agent doesn't reconstruct your logic. It uses it.

It works the other direction too.

FME's MCP Caller lets FME workflows reach out and use MCP tools that already exist elsewhere, Salesforce's, Snowflake’s, anyone's. 

A workflow can pull from a legacy system, enrich it with a model, and push the result to a vendor's MCP server. All in one pass.

So instead of choosing between "wait for vendors to build MCP" and "build everything yourself," organizations get both: access to the MCP ecosystem as it grows, and a way to bring everything else along with it.

What this actually takes

It’s worth being straight about the work involved. You build or reuse an FME workspace. You decide which workflows become tools. You choose what each tool accepts and the data that it returns.

That's not a hidden cost. That's the point.

Why this matters now

AI agents are only as useful as the data and systems they can actually reach. An agent that can reason about your operations but can't touch your real systems is a demo, not a deployment. The organizations getting real value from AI right now aren't the ones with the newest models.   They're the ones whose data infrastructure can actually meet those models halfway.

That's the practical case for treating MCP readiness as an integration problem rather than a vendor-roadmap problem. You don't have to wait for permission from every tool in your stack. You need a way to connect what you already have to the AI you want to use, on your terms, not on someone else's schedule.

That's been FME's job from the start. MCP just gave it a new name. Author: Don Murray , CEO/ Co-Founder Safe Software