Watch how most teams wire an agent to their data and you’ll see the same sprawl every time. One tool for the SQL warehouse. Another for the document store full of JSON the API team never quite normalized. A third bolted on for RAG, with its own embedding step and its own vector database. That’s three credentials to manage and three mental models to keep straight, and the agent is left guessing which one to reach for.
That works in a demo because the demo asks one kind of question. Real questions don’t stay in one lane.
Think about what someone actually asks an agent. “Which customers in this segment opened a ticket last quarter, and what were they complaining about?” The segment lives in a relational table. The tickets are semi-structured records, half schema and half free text. The complaints are unstructured prose that only a retrieval step can make sense of. One question, three kinds of data. If your agent has to cross three disconnected tools to answer it, it usually doesn’t. It answers from whichever source it happened to reach and presents a third of the picture with full confidence.
So here’s the case for one MCP server that speaks to all three. I don’t mean three servers hidden behind a wrapper. I mean one access layer where structured, semi-structured, and unstructured data all sit at the same level, and the agent asks for what it needs without having to know which silo holds it.
Start with the obvious win: the agent stops guessing about plumbing. Put the SQL query, the document search, and retrieval over a corpus on the same server, and the model picks its tool from the question instead of from some map of your infrastructure it had to be handed first. You spend fewer tokens explaining your topology, and you get fewer answers that quietly skipped a source.
The bigger win is that the hard, unglamorous parts get solved once instead of three times. Security is the clearest case. An agent should never hold the database password, and it shouldn’t hold the vector store’s API key either. Put both behind one server and you write the secret handling, the read-only scoping, the result caps, and the audit trail exactly once, enforced the same way no matter what kind of data gets touched. Spread it across three connections and every one of those is a place the security has to be gotten right, and at least one usually isn’t. I’ve watched teams lock down the SQL path beautifully and leave the document store wide open, because the second integration was a rush job nobody reviewed.
The same goes for the boring operational stuff. You get one place to see everything the agent can reach, and one audit surface that records every read in the same shape regardless of data type. When compliance asks what the agent touched, that’s a single answer instead of three log formats to reconcile. In a regulated shop, that one audit surface is often what makes the agent deployable at all.
There’s a quieter benefit that shows up months later. Data doesn’t respect your categories. That JSON blob you filed under semi-structured grows a free-text field that really wants retrieval. The report you used to serve from a table shows up as a PDF someone needs searched. With all three modes behind one server, promoting data from “just store it” to “embed and retrieve it” is a configuration change inside the same platform. You point a pipeline at a vector destination and re-run it, and the Postgres you already run works fine as the store. No new vendor to onboard, no separate security review to clear. The line between your data categories stops being a wall.
None of this makes the agent smarter. It just lets the agent see the whole picture instead of a third of it. Give a model one solid door into all of your data and it answers the question that actually got asked, not the slice that happened to sit behind whatever tool it reached first.
So before you stand up a third data connection for one agent, look at what you’re actually buying. It tends to be another security review, another audit format, and one more thing the agent has to be taught about how your data is laid out. The alternative is a single server that hands the agent every kind of data the same way, on request. Build that door once and the agent can spend its effort on the question instead of on finding its way to an answer.
Todd Fearn is the founder of Datris.ai and has spent about thirty years building data infrastructure for financial institutions. He writes about making AI agents useful in real production systems.