MCP is a big deal. This open standard (released by Anthropic in late 2024) is designed to make it simpler and easier for AI models to connect with external data, APIs and services. Intended to move us beyond model-specific approaches in the AI universe, MCP seeks to create a universal framework capable of interconnecting with any language model, small, medium or large. System architect and graph database expert (and founder) at in-memory graph database for real-time streaming analytics company Memgraph Dominik Tomicevic supports the protocol but notes it isn’t a stand-alone solution to every enterprise AI challenge.
AI interactions
Even though it’s really only been available in the world for about a year, developers and enterprises are already embracing the model context protocol, MCP, as a favoured way for AI models to interact with data and trigger real-world actions.
But Tomicevic provides some colour and says that initially, there was some scepticism because just one vendor, Anthropic, was behind it… and the early version was understandably fairly basic. But since then, adoption has grown significantly. Many model suppliers are building MCP support so their data and actions can be used by LLMs. Also, frameworks such as LangChain have adopted it. Some engineering teams use MCP to query data from the knowledge graphs that companies like Memgraph help them build. But interest is now expanding beyond the graph ecosystem, with teams seeing MCP as an accessible bridge into their LLM environments.
The real challenge, however, says Tomicevic, lies in ensuring the model truly understands what it’s querying and what the underlying data represents. If organisations don’t carefully plan for this aspect in their enterprise AI project, they’re unlikely to achieve the results they’re hoping for.
He tells us why.
Loose use, insecurities profuse
“Used loosely, MCP can introduce security vulnerabilities,” said Tomicevic. “It is becoming almost universally accepted that without strong curation and contextual grounding, LLMs can misfire, misuse tools, or behave unpredictably. Let me clarify what I mean by ‘tool’ i.e. external capabilities provided to the LLM, ranging from search, calculations and database queries to communication, transaction execution and more, with each exposed as an action or API endpoint through MCP.”
He explains that MCP allows firms to integrate a model with data sources (or tools), whereas before MCP, developers had to manually bring data into the model or chain multiple steps together. But as any good software engineer would recognise, alarm bells should sound when code is exposed to numerous external services and programs. Much like relying on open-source libraries without proper checks, firms could inadvertently leave the back door open to miscreants.
“Used too loosely, the MCP can introduce significant security vulnerabilities, including identity theft, data leakage, tool misuse, prompt injection and privilege escalation. When agents gain action rights (email, network changes, critical systems), an error or mis-selection can cause real harm. We therefore need to begin from a position of deep caution: define the most parsimonious ‘minimum viable toolset’ for each workflow, then slowly and carefully enable or disable tools dynamically based on context, user and task,” clarified Tomicevic.
Least-privilege design + explicit guardrails
It seems like the most prudent next step we can take here is pairing least-privilege design with explicit guardrails: strict scoping, audit trails, approvals for high-risk actions and environment tiers (e.g., dev/sandbox before production). Observability is essential for log prompts, tool selections, inputs/outputs and downstream effects so as to detect drift and roll back quickly. Finally, developers need to treat MCP configurations as code: version them, test them and stage changes just as with any other software.
But overall advises the Memgraph code guru, MCP’s promise is real, but so is its blast radius. The safest way to incorporate it is to assume failure is possible, keep potentially vulnerable operational surface area small and make reversibility and containment a standard design goal.
“But security isn’t actually the main possible MCP stumbling block. Perversely enough, by giving the LLM more capabilities, it might just get confused and end up charging too confidently down a completely wrong path,” said Tomicevic. “This problem mirrors context-window overload: too much information increases error rates. Developers still need to carefully curate the tools their LLMs can access, with best practice being to provide only a minimal, essential set. For more complex tasks, the most effective approach is to break them into smaller subtasks, often leveraging a graph-based strategy.”
As it stands, he thinks that MCP allows organisations to interact with external systems, but this shouldn’t turn into an uncontrolled flood of activity. Tasks need to be broken into manageable pieces, the right tools selected for each subtask, results aggregated and then fed back to the main LLM.
It’s your LLM, have it your way
“Without this approach, organisations risk running straight into MCP tool overload. Within our platform, a defined set of tools is always accessible to any LLM we build with a client. For each task, we have found that optimal business generative AI success comes when we constrain it to choose only the smallest set of tools the model really needs. So, if it requires up-to-date information, give it a web search tool; if it needs reliable calculations, give it a calculator tool and so on,” noted Tomicevic.
The truth that’s coming out of this discussion might lead us to understand that the best of today’s general-purpose models, like those from OpenAI, are trained to use built-in tools effectively. But even with a focused set of tools, organisations are not entirely out of the woods. Context remains a major challenge. Give an LLM a query tool and it runs queries; but without understanding the schema or what the data represents, it won’t generate accurate or meaningful queries.
An MCP-equipped LLM with the right tools but still no context is like giving someone access to a full set of business documentation since year one and asking them to produce an earnings report without telling them where anything is. Tools help, but they don’t replace context. To bridge this gap and create safer, smarter agents, software teams need a way to constrain and focus search – and practically, this is achieved through vector search or, increasingly, retrieval-augmented generation (RAG).
RAG useful, GraphRAG better?
“Both approaches are excellent and sufficient for many simple queries. But for higher-value AI, enterprises need a better way to provide relevant context at inference time. Across the developer community, this works best via an approach Microsoft Labs introduced about a year ago: GraphRAG, which is RAG implemented in a knowledge graph structure,” explained Tomicevic. “Why is this effective? GraphRAG embeds a clear, easy-to-follow knowledge graph layer that encodes entities, relationships and policies, so the model ‘knows what it’s doing’ before it reaches for a tool.”
Basic RAG with vectors reduces hallucinations by fetching evidence, but it can still be brittle when schemas are implicit. A knowledge graph constrains interpretation, provides typed schemas (who/what/where/time) and clarifies permissible actions. GraphRAG tightens the loop sufficiently, allowing the agent to then use MCP to execute bounded, controlled steps.
“This workflow of GraphRAG for structure and provenance, RAG for topical relevance and MCP for actions lowers error rates in two ways. First, it improves tool selection by aligning queries with known entities, relationships and capabilities. Second, it enables policy-aware execution (e.g., ‘Only managers can approve spend of over $5000’, ‘PII never leaves boundary X’), because rules live alongside data in the knowledge graph. Add dynamic tool whitelists based on graph context and enterprise tech leaders are well on their way to curbing hallucinations and over-permissioning. The net effect of these combined approaches is an MCP that uses zero inappropriate tools, makes fewer unsafe calls and provides AI app owners with a clear audit trail of what the agent ‘knew’ at any given point and why it acted as it did,” detailed Tomicevic.
Be clear on what MCP is… and isn’t
Overall, Tomicevic thinks that MCP is powerful, but he is concerned that many teams are rushing ahead without fully appreciating the importance of context for it to function effectively. Developers absolutely need the right safeguards around MCP to achieve reliable outcomes in any serious AI application.
“For example, if you want to automate a back-office function, the model might send an email, trigger a webhook, or update a system. MCP provides the mechanism for these actions, but you must carefully control how it’s used; failing to do so is irresponsible and invites unacceptable risk,” concluded Tomicevic. “Ideally, the system should dynamically enable or disable tools based on the specific request, giving the model only what it actually needs. Most teams aren’t there yet, but that must be the next step after MCP deployment and context constraining.”
In short, we can almost certainly agree that MCP is essential. While a competing protocol may emerge in the future, for now, if software engineers are integrating data or actions with LLMs, MCP is an excellent starting point, but it’s just a start. There are still tricky considerations to get right to fully use its potential.