System architect and graph database expert Dominik Tomicevic is a strong supporter of the protocol—but it isn’t a stand-alone solution to every enterprise AI challenge
In just over a year, developers and enterprises have embraced the model context protocol, MCP, as a favoured way for AI models to interact with data and trigger real-world actions. Early scepticism has given way to widespread adoption, with many model providers supporting MCP and frameworks like LangChain embracing it. Increasingly, developer teams are using it to query knowledge graphs, and interest is expanding beyond the graph ecosystem, with CIOs increasingly viewing MCP as an accessible bridge into their LLM environments.
The real challenge is ensuring the model 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 are hoping for. Let’s consider why.
Without due care, MCP can introduce security vulnerabilities
It is widely recognised that without strong curation and contextual grounding, LLMs can misfire or misuse tools. By ‘tools’, I mean external capabilities ranging from search, calculations, and database queries to communication and transaction execution, each exposed as an action or API endpoint via MCP. MCP allows firms to integrate models with data sources directly, replacing the need for manual data pipelines.
Caution is essential: using MCP without control can create security risks—identity theft, data leaks, prompt injection, or misuse of actions like sending emails or modifying systems—where even small errors can have real-world consequences.
Organisations should begin from a position of deep caution: define a parsimonious ‘minimum viable toolset’ for each workflow, and expand or restrict access over time. Tool availability should be governed based on context, user, and task. Combine least-privilege design with explicit guardrails: strict scoping, audit trails, approval workflows for high-risk actions, and a defined environment tiering. Observability is critical: log prompts, tool selections, inputs, outputs, and downstream effects to detect drift and enable rapid rollback.
The best approach for developers is to treat MCP configurations as code—versioned, tested, and carefully staged like any other software.
Limit the fallout from poorly configured MCP
MCP’s promise is real, but so is the potential damage it may cause. The risk-free way to incorporate it is to assume failure is possible, keep the operational surface area discrete, and make reversibility and containment a standard design goal. But security isn’t the main possible MCP stumbling block. By giving the LLM more capabilities, it may become confused and end up following a completely wrong path.
The problem is akin to context-window overload, where too much information may not increase accuracy, but increase errors. Developers should manage and curate the tools their LLMs can access, and ideally only provide a minimal, essential set. For more complex tasks, developers should break tasks into subtasks, and adopt a graph-based strategy. Without this approach, developers can run straight into MCP tool overload.
We’ve found that LLMs should always have access to a defined set of tools. For each task, optimal generative AI outcomes come from constraining the model to the smallest set of tools. For example, if it requires up-to-date information, provide a web search tool; if it needs calculations, give it a calculator, etc., while keeping the overall toolset minimal.
The best of today’s general-purpose models, like those from Anthropic, are trained to use built-in tools effectively. But even with a focused set of tools, context remains a challenge, and maybe the biggest. Give an LLM a query tool, and it runs queries—but without understanding the schema or the data, the results may be inaccurate or meaningless.
The reality is an MCP-equipped LLM with the right tools but with a weak grasp of 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.
To bridge this context gap and create safer, smarter agents, developers are increasingly relying on vector search or retrieval-augmented generation (RAG) to constrain and focus results.
GraphRAG beats plain RAG
Both approaches are excellent for simple queries, but for higher-value AI, enterprises need a better way to provide relevant context at inference. Microsoft Labs’ GraphRAG addresses this by combining the strengths of knowledge graphs with LLMs. GraphRAG embeds a clear, easy-to-follow knowledge graph layer that encodes entities, relationships, and policies, enabling the model to ground its reasoning before invoking external tools.
Vector-based RAG mitigates hallucinations by retrieving semantically similar context, but remains inherently under-constrained when schemas are implicit, untyped, or weakly enforced. This can lead to ambiguity in entity resolution, relationship inference, and action selection.
A combined approach to meet your AI ends
A knowledge graph introduces an explicit, typed schema layer—defining entities, relationships, temporal and spatial attributes, and policy constraints—thereby reducing interpretive entropy and constraining the model’s reasoning space.
GraphRAG tightens the retrieval-reasoning loop by coupling semantic search with graph traversal and schema-aware context assembly. This enables more deterministic grounding and disambiguation, allowing the agent to invoke MCP in a controlled, policy-compliant manner, and execute bounded actions with well-defined preconditions and minimal unintended side effects.
This workflow of GraphRAG for structure and provenance, RAG for topical relevance, and MCP for actions, lowers error rates in two ways. It improves tool selection by aligning queries with known entities and relationships, and it enables policy-aware execution, since rules embedded in the knowledge graph enforce constraints (e.g., ‘Only invoices from this supplier under this cost threshold will be approved’).
By adding dynamic tool whitelists based on graph context, enterprise AI builder teams can further curb hallucinations and over-permissioning. The net effect is an MCP system that avoids inappropriate tools, makes fewer risky decisions, and provides a clear audit trail of what the agent ‘knew’, and why it acted as it did.
Be clear on what MCP is and isn’t (yet)
MCP is powerful, but many teams underestimate the importance of context and safeguards. Actions such as sending emails, triggering webhooks, and updating systems must be tightly controlled to avoid significant risk. Tool access should be dynamically scoped per request—something many teams still overlook.
A robust ‘belt and braces’ approach around MCP is essential for any serious 2025–2026 AI application. That said, it is only a starting point—there are still complex challenges to address to fully realise its potential. AI is evolving fast, and it’s wise to not put all your eggs in even the most promising basket.
The author is CEO and Co-founder of Memgraph, a high-performance, in-memory graph database that serves as a real-time context engine for AI applications, powering enterprise solutions with richer context, sub-millisecond query performance, and explainable results that developers can trust
