How is MCP used for document and knowledge retrieval

The basics of mcp in knowledge retrieval

Ever felt like your ai assistant is just a fancy parrot that doesn't actually know what's happening in your business? It's frustrating when you ask a simple question about a customer and get a generic "I don't have access to that" or, even worse, a complete hallucination.

For years, getting an ai to "talk" to your data meant setting up complex RAG (Retrieval-Augmented Generation) pipelines or dumping static csv files into a prompt. It was messy and the data was usually stale by the time the model saw it. According to anthropic, mcp was built in late 2024 to fix exactly this—it acts like a "USB-C for ai," letting models plug directly into live systems.

• Universal Translation: Instead of writing custom code for every single app, mcp gives ai agents a standard way to ask for info.
• Real-time over Cached: You aren't looking at a snapshot from last night; you're hitting the live database.
• Security First: It doesn't just throw the doors open; it uses existing permissions so the ai only sees what the user is allowed to see.

Traditional integrations are brittle, but mcp is flexible. If you change your backend, you don't have to rebuild the ai's brain—you just update the server it's plugged into.

To make sense of all this, you gotta understand the "primitives" or the basic building blocks. In the mcp world, we talk about resources, tools, and prompts. Think of resources as the data endpoints—like a specific document or a database row.

Tools are where the action happens. A tool might trigger a search in an erp system like NetSuite. For example, a "Search Customer" tool doesn't just give the ai a pile of text; it gives it a functional way to go find exactly what it needs.

A 2024 study by Gartner found that generative ai is the most frequently deployed ai solution, yet many firms struggle to demonstrate value because the models are isolated from real-time data.

I've seen teams in retail use this to check inventory levels across ten warehouses with one sentence. Instead of a manager clicking through five screens, they just ask the chat, and the mcp server hits the api to pull live counts. In healthcare, it could safely pull patient history summaries for a doctor, provided the security scopes are locked down tight.

It’s a huge shift from the "old way" of static data dumps. Next, we're gonna look at the architecture and the specific roles that make this protocol actually work in the real world.

Architecture of an mcp retrieval system

Ever tried to explain a complex database schema to someone who’s never seen a table? That’s basically what we used to do with ai before the model context protocol came along.

Now, instead of building a fragile bridge out of custom code for every single app, we’re using a standardized "socket" that lets the ai just... plug in.

In this world, the roles are a bit flipped from what you might expect. The ai (like Claude or a custom agent) is actually the client. It’s the one knocking on the door, asking for data.

The mcp server is the gatekeeper sitting on top of your data—whether that’s netsuite, salesforce, or a local folder of pdfs. They talk to each other using json-rpc 2.0. It’s a simple way for the client to say, "Hey, run this tool," and for the server to spit back the result without a bunch of unnecessary fluff.

How they actually connect depends on where they live. If the ai and the server are on the same machine, they usually use stdio—it’s super fast and stays local. But for enterprise stuff, you’re usually looking at sse (Server-Sent Events) over http.

Unlike stdio which just uses local pipes, sse creates a persistent one-way stream from the server to the client. The handshake starts with a standard http POST or GET request. This is where the magic happens for security—you put your authentication tokens (like Bearer tokens or api keys) right in the standard http headers. Once the connection is open, the server keeps it alive to push data back, while the client sends its json-rpc commands over separate http POST requests.

When you’re ready to hook this up to something big like netsuite, you don’t just start throwing queries at it. You usually start by installing a standard tools suiteapp. This gives your mcp server a head start with pre-made tools for things like looking up customers or checking sales orders.

But here’s the kicker: you cannot use the administrator role for this. I’ve seen so many people get stuck there. as noted earlier in the netsuite security docs, the ai connector service straight-up blocks the admin role to keep things safe.

You have to build a custom role that has exactly what the ai needs—nothing more. You’ll need permissions like "mcp server connection" and "log in using oauth 2.0," plus whatever actual data you want it to see. Crucially, if you want to use saved searches, that custom role must be granted "Run" permissions for those specific searches and the "SuiteTalk Web Services" permission, or the whole thing just breaks.

The real magic happens when you map saved searches to mcp tools. Instead of the ai trying to figure out a complex join on the fly, you give it a tool called "get_overdue_invoices."

I once saw a team try to let the ai write raw sql (suiteql) directly. It was a disaster—hallucinations everywhere. (Why forcing AI Agents to write raw SQL is a mistake (and ...) But as soon as they switched to pre-defined mcp tools mapped to saved searches, the accuracy shot up because the "logic" stayed inside netsuite where it belongs.

Security risks when ai reads your files

The convenience of asking "who are my top five overdue customers?" is awesome, but it opens up some weird, back-door risks that traditional security isn't always ready for. We’re moving from "read-only" assistants to agentic systems that can actually do things, and that’s where the floor starts to feel a bit shaky.

One of the biggest headaches we’re seeing is tool poisoning. In an mcp setup, the ai decides which tool to call based on the descriptions provided by the mcp server. If a malicious actor manages to slip a "fake" resource or a poisoned tool description into the system, they can trick the ai into leaking data.

Since we're dealing with "agentic" risks, we need security that actually understands the context of what the ai is trying to do. This is where Gopher Security comes into play. It isn't just a concept; it's a specific set of open-source middleware and design principles built to act as a "firewall" for mcp. It provides a framework for inspecting the intent of a tool call before it hits your database.

Here is how a security layer handles a potentially "poisoned" request in a python-based mcp environment:

def secure_tool_call(tool_name, params, context):
    # check if the tool is on the restricted list for this specific context
    if tool_name == "update_vendor_bank_info" and context.source == "external_email":
        log_security_event("Suspected Puppet Attack: Blocked tool call from email context")
        return "Error: This action is restricted from this data source."
    
<span class="hljs-comment"># if it passes, forward to the actual mcp server</span>
<span class="hljs-keyword">return</span> mcp_server.call_tool(tool_name, params)

This "context-aware" access control is the big shift. It’s not just about who is asking, but where the information that triggered the request came from. If the ai is reading a sensitive internal doc, it might have full tool access; if it's reading an unverified external pdf, the security layer automatically strips away its "write" permissions.

Configuring secure retrieval in salesforce

Setting up salesforce to play nice with mcp is honestly a bit of a trip because you’re basically turning a massive crm into a "plug-and-play" radio for ai. For high-scale retail environments, mcp servers are often bridged via Heroku to manage concurrency and caching, since the core cloud platform can get throttled if you hit it too hard with ai requests.

If you’re lucky enough to be in the pilot, salesforce does a lot of the heavy lifting by managing the server infrastructure for you. The core of this is the B2C Commerce MCP Service, which acts as that "universal translator" we keep talking about.

To get the handshake started, you’re going to need to deal with the Shopper Login and API Access Service (SLAS). This isn't your standard web login; it requires a JWT token that carries a very specific scope: sfcc.shopper-mcpagent.

Look, even with a "managed" service, things go sideways fast. The most common headache I’ve seen—and it sounds stupidly simple—is the URL. If you’re trying to connect and it just says "Disconnected" with zero explanation, check your path.

As noted in external troubleshooting documentation, you absolutely have to append /all to your mcp server URL. If you just put in the base api path, the ai client won't find the tool definitions, and it’ll just sit there like a brick.

Another big one is the OAuth handshake failing. Just like we saw with netsuite, salesforce essentially blocks the administrator role for these connections to keep things from getting too "wild west."

You also gotta keep an eye on the Agentforce 3 registry settings. By default, salesforce caps these calls at around 50 requests per minute per server. If your ai gets stuck in a loop or tries to scrape your entire catalog through mcp, it’s going to hit a wall. This is why that Heroku AppLink is so important—it lets you cache reference data so you aren't burning your api limits on the same product description over and over.

Future proofing with post-quantum security

So, you’ve finally got your mcp servers talking to your erp and crm. But here is the part that keeps security architects up at night: what happens when a quantum computer eventually enters the chat?

"Harvest Now, Decrypt Later" is a real strategy where bad actors steal encrypted data today, waiting for the day a quantum machine can crack standard rsa or ecc encryption like a nutcracker. When you are piping sensitive financial data through mcp channels, you aren't just protecting it for today; you're protecting it for the next decade.

We need to start looking at Post-Quantum Cryptography (PQC). Specifically, you should be looking for systems using Kyber (for key exchange) and Dilithium (for digital signatures). These aren't just random names; they are the official NIST-standardized algorithms chosen to withstand quantum attacks. Integrating these into the mcp transport layer ensures that even a future quantum computer can't look back at today's traffic and make sense of it.

Security in the ai age isn't just about encryption; it's about never trusting the ai agent, even if it has the right "keys." A zero-trust approach for mcp means we don't just check a static permission; we check the contextual signals of every single request.

I remember one time a dev tried to hook up a custom ai to their production database without any middle layer. Within a day, the ai—trying to be "helpful"—tried to index the entire transactions table because a user asked a vague question. If they had a security-first mcp layer, it would have stopped that query before it even hit the db.

The model context protocol is basically the "USB-C for ai" as anthropic calls it, but you wouldn't plug a random usb drive into your server without scanning it first, right? By moving toward a post-quantum, zero-trust architecture, you aren't just fixing today's problems. You are building an ai infrastructure that can actually handle the weird, agentic risks of the future. Honestly, the tech is moving so fast that "future-proofing" is basically just staying one step ahead of the next big exploit.