From answering questions to holding a conversation: what MCP integration looks like on a real project

One of our current projects is a language course discovery platform. The client had already done serious groundwork: a trained ML model, a clean dataset, a chatbot that answered user questions accurately. By most measures, the technical foundation was solid.

But the product wasn't behaving like a conversation. A user would type something — "I want to study in Ireland, I have a budget of around €5,000 to €10,000" — and the bot would respond correctly and then wait. No follow-up. No clarification. No offer to help with the next step. Every exchange reset. The model was answering, but it wasn't listening.

That's the problem we were brought in to solve. And the architecture decision at the centre of it was whether to use MCP.

What MCP is, and why it matters here

MCP — Model Context Protocol — is a communication standard that allows an AI model to talk directly to backend systems: databases, APIs, application logic. It was introduced by Anthropic in late 2024 and has since become one of the more important infrastructure decisions for teams building AI-powered products.

The alternative — which most early AI integrations use — routes through intermediate layers: the model sends a request, an API layer queries the database, the result travels back through the same layers, and the model finally receives it. Every layer adds latency. Every layer is a potential point of failure. Every layer limits what context the model can access in real time.

MCP removes those intermediate layers. The model connects directly. The result is faster responses — but more importantly, it changes what the conversation can do, because the model now has live access to the data it needs to be genuinely useful, not just technically correct.

The distinction matters most in products where the quality of the conversation is the product. A chatbot that answers accurately but can't carry context, ask follow-ups, or act on what it knows isn't a conversational product. It's a search interface with a friendlier wrapper.

What the client needed — and what that required technically

The client's goal was specific: a bot that behaves the way a knowledgeable human advisor would. If a user mentions their budget, the bot remembers it. If the user asks about visa requirements halfway through a conversation about course options, the bot handles that without losing the thread. If the bot can help take a next step — shortlisting courses, booking a callback, sending a comparison — it offers to do so.

That kind of behaviour requires three things working together: the model needs to hold context across a session, it needs access to live product data, and it needs to be able to trigger actions in the backend.

We talked through this with Anastasiya, our PM on the project, to understand where the architecture decision actually came from — and why the problem couldn't be solved at the model level.

Anastasiya — PM

The model itself wasn't the problem. The issue was how it connected to everything else. All the data — course inventory, pricing, availability — was sitting in the database, but the model couldn't reach it in real time. It was responding from what it had been trained on, not from what was actually true right now. And there was no way for it to take action. It could tell you a course existed. It couldn't help you do anything about it. The POC we built demonstrated that an MCP server could close that gap immediately — the model, connected directly to the backend, could pull live data mid-conversation, maintain session context, and trigger backend actions without the latency of intermediate layers.

Who should lead this kind of integration — and why

This is a question we get asked in different forms on almost every AI integration project: do you need an AI/ML specialist to implement this?

For MCP integration, the answer is no — and understanding why matters for how you scope and budget this work.

MCP is not model development. You are not training, fine-tuning, or modifying the model itself. You are building the connection layer between an existing model and your existing systems. The hardest part isn't connecting the model — it's defining precisely what the model can safely and stably access in a real production environment. That requires someone who knows your backend deeply, not someone who knows models deeply.

Anastasiya — PM

Vlad is our backend developer on this project. Vlad has been inside this codebase from the beginning. He knows the backend, he knows the product logic, he understands how the data is structured and where the edge cases are. That context is worth more here than AI-specific credentials. Someone coming in from outside, even with strong ML experience, would need months to reach where he already is. The integration has to fit the existing system precisely — and that precision comes from product knowledge, not model knowledge.

This has a practical implication for teams planning similar work: the right person to lead an MCP integration is probably already on your team.

The technical details that actually matter

Getting the MCP integration working is the beginning, not the end. What determines whether it holds in production comes down to four things that don't get discussed enough in most writeups on this topic.

• Tool boundaries. The model needs clearly defined limits on what it can query and what it cannot touch. Not every table in the database is relevant to a user conversation — and some data should never be accessible at the model layer under any circumstances. Defining those boundaries upfront is a security and product decision, not just a technical one.

• Permission logic. Some actions the model can take autonomously — pulling course data, remembering session context, generating a shortlist. Others require explicit user confirmation before they execute: booking a callback, sending a comparison email, initiating any transaction-adjacent step. The distinction between automatic and confirmed actions has to be designed deliberately, not left to emerge from how the integration happens to behave.

• Fallback behaviour. Live data connections fail. Course availability changes between the start and end of a session. Pricing data can be incomplete. The model needs to handle these gracefully — acknowledging what it doesn't know, offering what it does, and never presenting stale data as current. Fallback logic is easy to skip and expensive to fix in production.

• Observability. In a traditional product, you log errors. In an MCP-integrated product, you need to log much more: tool calls made by the model, latency per call, failed actions, the data returned from backend queries, how the model interpreted user intent, and when fallback behaviour triggered. Without this, debugging production issues becomes guesswork.

• Testing. Testing an MCP integration means testing more than conversation quality. It means testing backend integration behaviour, permission flows, action confirmation logic, and edge cases in the data — independently of whether the dialogue reads well. A conversation can feel natural and still have a broken permission boundary underneath it.

How we structured the engagement options

Part of what we do on projects like this is give clients a realistic picture of their options — not just the technical ones, but the delivery and budget ones too. On this project, we presented three paths.

• The first: our team handles the full MCP integration. Clean delivery, full accountability, highest cost.

• The second: our backend developer works alongside their in-house engineer — shared delivery, knowledge transfer built in, lower cost. The client's engineer comes out of the engagement with hands-on MCP experience on their own system. This is the option the client is leaning toward, and we think it's the right call for where they are.

• The third: we advise while their team implements. Lowest cost, highest risk if their engineer hasn't worked with MCP before.

The second option works particularly well for integrations like this one, where the client has a capable technical team and a long-term product roadmap. The integration isn't a one-time job — it will need to evolve as the product grows. Having internal capability built in from the start is worth the slightly longer timeline.

What changes when this is done well 

The version of this product that exists at the end of a well-executed MCP integration is fundamentally different from the one the client started with — not because the model changed, but because the model can now do its job.

A user who arrives with a budget, a timeline, and a vague idea of what they want can have a real conversation. The bot can ask the right follow-up questions, pull accurate course data in real time, remember what was established earlier in the session, and help move toward a decision.

The gap between "I have a question" and "I have a next step" closes significantly — and that gap is where conversion happens, where user trust is built or lost, and where the product either justifies itself or doesn't.

For teams evaluating whether their AI product needs this kind of architecture change, the question is simple: is the conversation the product? If the answer is yes, the connection layer is not a technical detail. It is the product architecture.