Webinar: What It Takes to Build AI-Ready Telco Clouds
Shameless plug, Fierce Network hosted a webinar with Nokia, Everpure, and Red Hat. In this webinar, Nokia, Red Hat, and Everpure will share perspectives on the strategic considerations shaping next-generation telco cloud design—from standardization and lifecycle management to data readiness, operational efficiency, and support for distributed environments from core to edge. The session will explore how service providers can think about building a modern telco cloud foundation that is better prepared for automation, analytics, and long-term innovation. Check out the Webinar here
Keeping Your Fleet Up-to-Date Just Got a Lot Easier
Did you know: 95% of Purity upgrades now finish in under 90 minutes. You can run them in parallel and your whole fleet finishes in the same time it takes to do one. Every Purity release delivers more: better performance, new capabilities, the latest security updates. Staying current is how you keep pulling value out of hardware you already own. At Everpure, upgrades shouldn't be something you plan your week around, or something that delays the benefits every Purity release brings. Self-Service Upgrades in Pure1 (SSU) let you upgrade Purity on your own schedule, directly from Pure1, without opening a support ticket. It has quietly become the most popular way customers keep their fleets current. What's new: Automated SSU SSU has always given you full control over the upgrade flow, with mandatory pauses after each major step (health check, download, installation) and deciding when to continue. For teams who want to validate at every checkpoint, that is exactly how it should work and that manual flow isn't going anywhere. For everyone else, it meant mandatory delays and too much hands-on involvement. Arrays sitting idle between phases, waiting for someone to click through.More time spent on an upgrade than necessary, and enough that some teams never tried SSU at all, and kept pushing upgrades for later. Automated SSU is the option for those who want to go fast without giving anything up. Pick any number of appliances, select the target Purity version, authenticate, and go. The workflow runs to completion on its own, non-disruptive by design, so your workloads keep running throughout. If anything goes wrong, the upgrade pauses on that appliance and a proactive case opens with Everpure Support. Over 100 automatic health checks run before and during the upgrade, and the workflow won't move past a critical failure. First response from Support is typically 30 minutes for install issues, 60 minutes for others. Built for fleets Need to cover your whole fleet? Select your appliances in bulk, hit go, and they upgrade in parallel, finishing in the same time it takes to do one. The Software Lifecycle dashboard shows you exactly what's running, what's done, and what (if anything) needs your attention. If your target version is several releases ahead, SSU computes the upgrade path and runs the intermediate hops on its own. Get started in 15 minutes Not on SSU yet? The one-time setup takes about 15 minutes: enable cloud connection on each appliance from the CLI, then bulk-install the Purity Upgrade Agent from Pure1. After that, it is ready when you need it. Give Automated SSU a try. It really is easier than you think. Full SSU prerequisites and setup guideDenver Pure User Group (PUG) meetup
Details Our next Denver Pure User Group (PUG) meetup is all about protecting and securing all your data. Join us to connect, learn, and engage with your local IT peers around strategies to battle ransomware, speed up recovery, and prepare business continuity solutions for disaster recovery. Discuss a tiered resiliency architecture and strategies to implement before, during, and after a cyber incident. Topic : Cyber Resilience and 1touch Venue Prost Brewing Co. - Northglenn Biergarten 351 W 104th Ave Unit A Northglenn, CO, 80234 Speaker Scott Taylor Director, Cyber Resilience, Field Solutions Architect Everpure Doug Gregory Area Vice President, 1touch Everpure Register here!Security Is Not a Feature — It's the Foundation
Let's get something out of the way upfront: this is not a ransomware horror story. This is not a "cyber resilience framework" deep-dive full of three-letter acronyms that could potentially make your eyes glaze over if it's not your cup of tea. And this is definitely not a pitch deck disguised as a blog post. This is the real story of how Everpure thinks about security — at the architecture level — and why that distinction matters more than most people realize when they're evaluating storage platforms. Because here's the thing: security isn't a bolt-on. It's not a checkbox. And it's certainly not a conversation you should have to schedule separately from the one about performance or reliability. At Everpure, security is baked in from the ground up — and once you understand how, you'll never look at a storage spec sheet the same way again. Start With the Five S's At Everpure, we talk a lot about what we call the Five S's of data: Simplicity, Speed, Scale, Sustainability, and Security. They're not independent pillars — they're interlocking principles that define every design decision we make. Simplicity because complexity is the enemy of agility. If you can't iterate quickly, you can't grow. Speed because we've been all-flash since day one — full stop. Every generation of our platform has been optimized around flash, not retrofitted for it. Scale because data doesn't stop growing, and your storage shouldn't hit a wall when your business doesn't. Sustainability because power, cooling, and physical footprint are real constraints — especially now, as those pressures trickle down from hyperscalers to everyone else. Security because none of the other four matter if your data isn't protected. Security is the one that tends to get either oversimplified ("we encrypt everything") or overcomplicated ("here's our 47-page compliance matrix"). Neither is helpful. What's helpful is understanding how it works, why it's different, and what it means in a real conversation with a real customer. The Compliance Landscape: What Customers Are Actually Asking About Before we get into the architecture, let's talk about the validations — because customers are increasingly asking about them, and the answers matter. FIPS 140-3 is the latest standard from the Cryptographic Module Validation Program (CMVP), managed by NIST. It validates that a cryptographic module — the thing actually doing the encryption — meets a defined security standard. Everpure's FlashArray is FIPS 140-3 validated. That's the current gold standard, and it matters especially as post-quantum cryptography conversations start entering the room. (More on that in a moment.) Common Criteria is an international standard for evaluating the security of IT products — not just storage, but networking, applications, hardware modules, and more. Everpure's FlashArray is certified under the Network Device collaborative Protection Profile (NDcPP) via NIAP, while FlashBlade holds an EAL2 certification. Independent testing and verification confirm that each platform meets its defined security target. You can actually enable Common Criteria mode directly on a FlashArray — it's a CLI command, not a professional services engagement. PCI DSS compatibility is table stakes in financial services, but it increasingly shows up in other industries too. It means end-to-end data masking, encryption in-flight and at rest, and a well-documented audit trail. Everpure's platforms are designed to support PCI DSS requirements natively — though it's worth noting that PCI DSS certification belongs to the merchant environment as a whole, not to any individual storage component. TLS 1.2 and 1.3 are the current standards for securing data in-flight at the management layer. Everpure standardizes these across all management communications — and yes, you can turn off older cipher suites if your security posture requires it. TAA Compliance means that Everpure's hardware is manufactured in the United States. For customers in regulated industries or government, this isn't a nice-to-have — it's a requirement. And for anyone who cares about supply chain transparency, Everpure can show its work. None of this is marketing fluff. These are independently validated, publicly verifiable certifications. You can find all of them — current CVE database, FIPS status, NIST 800-53 alignment, media sanitization documentation — at our Customer Trust portal. Bookmark it as It's fully public-facing and constantly updated. The Hardware Story: Why No Keys on the Drive Is the Point Here's where things get interesting. Take a Direct Flash Module — Everpure's approach to flash — and look at what's not on it. No CPU. No memory. No encryption keys. It is not a self-contained storage array. It is purpose-built flash media, and everything else — the intelligence, the encryption, the key management — lives in software. Why does that matter? Because self-encrypting drives (SEDs) are a pain. Anyone who's managed them in a regulated environment knows this intimately. When the encryption is in the hardware, you inherit all the complexity that comes with it: drive-level key management, FTL overhead, KMIP integration headaches, and the ever-present risk that a single drive failure or misconfiguration creates a data accessibility nightmare. Everpure's approach flips this entirely. Because the Direct Flash Module has no CPU, no memory, and no keys, all encryption is handled at the software layer — in Purity, running across the entire system. This means no hardware dependency, no FTL management overhead, and no encryption key tied to a specific piece of media. The portability this creates is remarkable. And as you'll see in a moment, it's the foundation of everything else. How Everpure's Encryption Actually Works Let's peel back the layers here, because this is genuinely cool — and it's the kind of thing that separates a confident storage conversation from a "let me get back to you" one. Everpure's encryption architecture is built around three components: The Data Encryption Key (DEK) is the actual key used to encrypt customer data. There's one per array, and it doesn't change. You might think: why would you never rotate the key that's protecting your data? The answer is that the DEK never needs to rotate because of what wraps it. The Key Encrypting Key (KEK) is a key that encrypts other keys — specifically, it wraps the DEK. This is standard cryptographic practice, and it's the mechanism that makes key rotation safe, fast, and completely transparent to the workload. The Armored DEK is the DEK after it's been wrapped by the KEK. This is the piece that gets distributed. At no point is the raw Data Encryption Key exposed in clear text. It's always wrapped, always protected. Here's where the architecture gets elegant: when a FlashArray or FlashBlade initializes, it generates a KEK. That KEK wraps the DEK to create the Armored DEK. The Armored DEK is stored as a complete copy in every Direct Flash Module header — but it cannot be decrypted without the KEK. The KEK itself is derived from a scrambled key, which is split into individual shares and distributed one per DFM header using a sharding algorithm that requires a quorum to reconstruct. What does quorum mean in practice? The system can tolerate drive losses and still unlock all data, as long as enough DFMs remain present and healthy to reconstruct the scrambled key. No single drive is a single point of failure for your encryption keys. When a read request comes in, here's what happens: the system reconstructs the scrambled key from a quorum of DFM shares, derives the KEK, and uses it to unwrap the Armored DEK — exposing the DEK temporarily in memory, never persisted in clear text — and uses it to decrypt the data. The process is reversed for writes. At no point is customer data stored or persisted in clear text. Everything written to NVRAM is encrypted before it ever reaches upper-level system processes. This isn't "we encrypt everything." This is a specifically designed cryptographic architecture that is portable, resilient, and opaque to any unauthorized party — including someone who physically removes a drive. Key Rotation: The Part Most Vendors Skip By default, Everpure rotates the Key Encrypting Key every 24 hours. Automatically. No KMIP server required. No scheduled maintenance window. It just happens. When a KEK rotates, the system generates a new one, re-encrypts the Armored DEK, and redistributes the updated scrambled key shares across all DFM headers. The DEK itself doesn't change — the workload never sees it — but the wrapping layer that protects it is refreshed daily. When drives are added or removed, the system treats this as a high availability event: it generates a new KEK immediately, re-encrypts everything, and rebalances the shards across the new drive configuration. The key material always matches the current system state. And when a DFM is removed from the system? The scrambled key shares on that drive correspond to a KEK that no longer exists — or will be rotated away within 24 hours. A removed drive becomes cryptographically useless. This is how Everpure delivers what some would call "instant media sanitization" — not by wiping the drive, but by invalidating the key that makes its contents meaningful. Rapid Data Locking: When You Need the Nuclear Option For environments where security isn't just a compliance requirement but a physical reality — air-gapped facilities, defense deployments, high-security data centers — Everpure has a capability called Rapid Data Locking (RDL). The concept: the Key Encrypting Key can be placed on a pair of hardware security tokens (one YubiKey per controller, two total) and inserted into the array. As long as the tokens are present, the array operates normally. If they are removed and the array is subsequently rebooted or power-cycled, the array cannot complete startup without the tokens present — the data remains physically intact, but it is cryptographically inaccessible. The array becomes, in the most literal sense, an expensive brick. Reinsert the tokens and power the array back on, and it boots up normally. This is the kind of capability that used to require expensive, bespoke security architecture. For Everpure customers, it's a feature of the platform. Dark Sites Are Getting Less Dark One more topic worth addressing: dark site deployments. Air-gapped environments have always involved painful tradeoffs — disconnected from cloud management, manual support processes, limited visibility into system health. That's changing. Dark site customers can now see their assets within Pure1 — subscriptions, health status, the ability to open and manage support cases — without compromising their air-gap requirements. Log obfuscation tooling is available today and will be integrated directly into the platform going forward, giving customers granular control over what telemetry leaves their environment and when. For partners and customers managing dark site deployments, this is a meaningful quality-of-life improvement. And it's consistent with how Everpure builds everything: the security architecture makes the operational flexibility possible, not the other way around. The Takeaway Security conversations in the storage industry tend to go one of two ways: a recitation of certifications that nobody fully understands, or a vague reassurance that "everything is encrypted." Neither builds confidence. Neither answers the real question, which is: how does this actually work, and why should I trust it? Everpure's answer starts with architecture. Software-managed encryption, no hardware key dependency, automatic key rotation, cryptographic portability, quorum-based scrambled key distribution, and capabilities like Rapid Data Locking that scale to the most demanding security requirements in the world. The certifications — FIPS 140-3, Common Criteria, TLS 1.3, TAA — aren't the story. They're the evidence. The story is that security was designed in from the beginning, not layered on afterward. That's a meaningful difference. And now you know why.Pure User Group - July 2026
Hit the Links... Cincinnati PUG Style What’s up Cincinnati Pure Community? I hope you all are doing well, preparing for the approaching holiday weekend, and making those summer vacation plans. Speaking of, if you are making those summer vacation plans, make sure to avoid the week of June 29th. Why? We’re hosting our next Pure User Group meetup on Wednesday, July 1st, from 3-6pm at Oakley Greens. Join the community once again for an afternoon of conversation, and hit the links afterwards for some community fun! Call for Speakers With that said, we are looking for a speaker for the meetup. I know some don’t enjoy speaking in public. That’s completely understandable. I was one of those people for a long time. If you’re considering speaking, but are nervous, here are a couple of ideas that I can offer to help you. Bring a Friend - Whether it’s a colleague, a partner, or an application vendor; ask someone to present with you. This way you can split the topic in half, and you can help each other if one of you get “stuck” during the presentation. Just make sure the topic is how you and the partner / vendor together helped your business be successful. Upcoming Project - When asked to present, we immediately consider a project or task that we recently completed, that we want to share the success of the project with the community. Another speaking option would be to share an upcoming project or task, and ask the community their thoughts and feedback. Something along the lines, this is what we’re doing, we plan on doing this, but I’ve also considering that. Community, what do you think? Have you done something similar? If so, what worked well? What didn’t? Lean on Everpure - Have a topic in mind, but need help from a content or delivery perspective. A member of the Everpure team would be more than happy to help. We can help with content creation, or create a lab environment that would allow you to perform your own demo. Interested in speaking? Let charles_sheppar or your Everpure AE/SE know. Again, we are all happy to help. Attendance... It's Summer Y'all Make sure to click 'Attending' on the event page to let us know you’re coming. We know the days around the July 4th holiday are a popular choice for vacations, so if we determine that attendance might be a little “light”, we can reschedule for mid to late July. Topics To Be Determined, but we have some ideas. Let's get back to basics and talk about performance and capacity management? Too boring, how about a Fusion enablement session? Or, let's discuss how the community is managing the current supply chain crisis? Or, we can do a little bit of everything. Again, Everpure doesn't determine the topic, the community does. Date & Time Wednesday, July 1st, 3-6pm Location Oakley Greens, 3065 Vandercar Way, Cincinnati, OH 45209 https://oakleygreens.com/Part 2: MCP Is Interesting. Everpure Fusion Makes It Useful.
In Part 1, I tried to give MCP a proper “…splanation,” mostly because the first several times I heard people talking about Model Context Protocol, I had the same look Joey had in Friends when the salesman asked him if his friends ever had a conversation and he just nodded along without really knowing what they were talking about. That was me. MCP this. MCP server that. Agentic AI. Tool calling. Context windows. Protocols. Hosts. Clients. Servers. At some point, I realized I was nodding with the confidence of a man who had understood approximately 41% of the conversation and was hoping nobody asked a follow-up question. The simple version is this: MCP is a standard way for AI applications to connect to tools and data. It is not the AI model itself. It is not the magic brain. It is the plumbing that lets the AI reach into approved systems, ask better questions, retrieve useful context, and potentially take action through well-defined tools. That is important in the abstract. But for Everpure customers and prospects, it becomes much more interesting when we stop talking about MCP as a general AI concept and start talking about what it could mean for storage operations, data infrastructure, and Everpure Fusion. Because this is where the conversation moves from “AI is coming someday” to “your infrastructure may already need to be ready for how AI will interact with it.” Everpure recently published a blog with a sneak peek of the Everpure Fusion MCP Server, describing it as an open-source service that connects AI assistants to Everpure Fusion storage fleets through the Model Context Protocol. The important part is not simply that an AI assistant can talk to storage. That would be interesting, but it would also be easy to misunderstand. The important part is that the assistant can interact with the storage environment through the Fusion control plane, which already understands fleet-wide context across FlashArray and FlashBlade. That distinction matters. Without Fusion, many environments are still managed in a way that looks very familiar to anyone who has spent time supporting infrastructure. One array over here. Another array over there. Scripts in one folder. Notes in another. Naming standards that started strong and then apparently met reality. Screenshots in tickets. Tribal knowledge in the heads of a few people who somehow remember which workload lives where, which array is doing what, and why nobody should touch that one volume because “there was a reason,” even if nobody is entirely sure what the reason was anymore. That model may work, but it does not scale gracefully. More importantly, it is not especially friendly to automation, and it is definitely not ideal for AI-assisted operations. Most troubleshooting in mature environments is not hard because people lack tools. It is hard because the context is not immediately obvious. The storage admin has one view. The DBA has another view. The virtualization team has another view. The application owner has a completely different view, usually delivered through a ticket that says something deeply scientific like “the app feels slow.” Everyone may be looking at a valid piece of the puzzle, but the real work is in the correlation. Which volume maps to which workload? Which array is hosting it? What did latency look like during the reported window? Were IOPS elevated? Was bandwidth constrained? Did anything change recently? Are we looking at a storage issue, a database issue, an application issue, a noisy neighbor, a misconfigured VM, a bad query, or just another case of “the network is innocent until proven guilty, but still somehow looks suspicious standing there”? That is where Fusion and MCP together become compelling. The Everpure Fusion MCP example makes the idea real. Instead of forcing an administrator to manually build low-level REST API calls or jump between tools, the MCP-aware AI assistant can query Fusion through higher-level tools exposed by the MCP server. In the example Everpure blog described, a storage admin can ask about workloads and volumes supporting a production SQL environment, including arrays, IOPS, latency, and bandwidth over a recent time window. The assistant can then correlate that storage perspective with information from another MCP server, such as SQL Server context around database files, wait types, and query behavior. That does not mean the AI replaces the storage admin. It does not mean the AI replaces the DBA. It does not mean everyone goes to lunch while the robot fixes production. And this is where I need to bring in The Big Bang Theory again, because apparently this is who I am now. There is a scene in the show where Raj is very open to the idea of aliens and extraterrestrial life. At the planetarium, Raj can look at flashes of light in the sky and talk about how scientists cannot fully rule out the possibility of alien civilizations. It is funny because Raj is a scientist, but he is also Raj, so the line between rigorous possibility and “maybe the aliens are waving at us” gets wonderfully blurry. That is how some people talk about AI operations right now. A light flashes in the sky, and suddenly someone is ready to announce that the robots are here to run the data center. Let’s not do that. The point is not that the AI is an alien civilization arriving to take over infrastructure operations. The point is that the interface is changing. The way humans interact with infrastructure is starting to move from manual lookup, command execution, and tribal knowledge toward assisted reasoning, guided action, and cross-system correlation. That is much more practical than aliens. It is also much more useful. Fusion already gives customers a fleet-wide control plane. It gives you the ability to think above individual arrays, above one-off configuration, and above the old habit of managing infrastructure like every system is its own little island with its own weather pattern. MCP gives that control plane another interface, one designed for the way AI agents work. This is why Fusion adoption matters. If your environment is still managed mostly array by array, script by script, ticket by ticket, and screenshot by screenshot, then AI can only help so much. It may summarize the pain beautifully, but it is still summarizing pain. When you use Fusion to create a more consistent, policy-driven, fleet-aware operating model, you are not just modernizing storage management. You are making the environment more understandable to automation, to operations teams, and now to AI agents that need structured context in order to be useful. That is a very different conversation from “look, the AI can query storage.” The better conversation is this: if AI is going to become part of operational workflows, then your infrastructure needs to be ready to participate in those workflows. Fusion is one of the ways you prepare for that. Not someday. Now. And Fusion is not the only example of this direction. Another Everpure technical article shows how an MCP server can be built to integrate with FlashBlade, allowing an AI assistant to query system data and even take direct actions through a natural-language interface. That example is useful because it shows the bridge between the old world and the new one. In the old world, storage management often meant CLI commands, scripts, API calls, screenshots, and specialized knowledge living in the heads of a few very tired people. In the new world, those capabilities can be surfaced through an AI-assisted experience that understands the available tools and can help operators ask better questions in plain English. Again, that does not mean the AI should blindly run your infrastructure while everyone disappears. Please do not read this article and tell your change advisory board that “the blog guy said the robot can handle it.” That is not the point, and I would like to remain welcome in polite infrastructure society. The point is that the operational model is changing. For years, we have talked about automation in infrastructure, but a lot of what we called automation still required a human to know exactly what to automate, where to look, which command to run, which script was safe, which API endpoint mattered, and which piece of documentation had not quietly aged into fiction. AI-assisted operations changes the interaction pattern. Instead of always beginning with the operator knowing the exact command or API call, the operator can begin with the question. Why did this workload slow down? Which volumes support this application? What changed in the last four hours? Which arrays are carrying the highest latency? Which workloads are consuming the most bandwidth? Which policies are inconsistent across the fleet? Where do we have capacity pressure? Which storage objects are tied to this SQL environment? Those are the kinds of questions humans actually ask when something is happening. MCP gives AI assistants a standard way to ask approved systems for the data behind those questions. Fusion gives the storage estate a more consistent, policy-aware, fleet-level way to answer. That combination is where the opportunity lives. Now, because this is enterprise technology and not a children’s book, we also need to talk about the dangerous part. One of the readers posted this comment on Linked in yesterday: The moment an AI system can access tools and data, the conversation changes. A chatbot that gives a bad answer is annoying. An agent that takes the wrong action in a business system can become a real incident. If a model can read sensitive files, query databases, send messages, modify records, trigger workflows, or touch infrastructure, then security is not a feature. Security is the premise. This is where some of the MCP enthusiasm needs adult supervision. We have spent years telling users not to click strange links, not to approve unknown applications, not to reuse passwords, and not to download random files. Now we are building systems where an AI assistant might read strange content, call external tools, and act on behalf of the user. That can be incredibly powerful, but only if we are honest about the risk. In some ways, MCP may expose organizational problems faster. If your data is scattered, stale, contradictory, or politically curated, an AI agent connected to it will not magically produce truth. It may simply produce a more polished version of the confusion. If your workflows are unclear, connecting AI to them may help automate the ambiguity, which is not quite the same thing as progress. The model can gather information, call tools, and complete steps, but people still need to define what should happen, what should not happen, what requires approval, and what good looks like. For Everpure customers and prospects, the more important question is not whether MCP is interesting. It is whether your environment is ready for this kind of interaction. That is where I would encourage customers to take a serious look at Fusion. Not because Fusion is another checkbox on a feature list, and not because every new technology conversation needs to end with someone saying “platform” three times into a mirror. Fusion matters because it changes the operational model. It gives you a way to manage data infrastructure as a fleet, with policy, consistency, automation, and context. Those are exactly the things AI agents need if they are going to do more than produce nicely formatted guesses. If you already met all the prerequisites (Purity 6.8.+, LDAP enabled), use it. Explore it. Get comfortable with it. Stop thinking about Fusion as something reserved for a future automation project after everyone finally gets through the current list of fires, renewals, upgrades, and meetings that should have been emails. MCP may be the plumbing that helps AI connect to the enterprise. Fusion helps make the storage environment worth connecting to. And that is the real call to action. Fusion is how Everpure customers make sure their data infrastructure is ready for it. Appreciate you reading. Dmitry Gorbatov © 2025 Dmitry Gorbatov | #dmitrywashereMCP, Joey Tribbiani, and the Moment AI Needed Plumbing - Part 1
People close to me know that I have a very annoying habit of memorizing, remembering, and using movie and TV show lines in normal conversation. I wish I could tell you this is a carefully curated personality trait, but it is probably closer to a long-running defect in the #dmitrywashere operating system. Some people remember birthdays. Some people remember where they parked. I remember a line from a sitcom episode that aired before half the people reading this had a LinkedIn profile. My two favorite sources are Friends and The Big Bang Theory, which probably says something about me that I am not emotionally prepared to unpack in public. There is a scene from Friends that has lived rent-free in my head for years, mostly because it captures something deeply human and mildly embarrassing. A salesman is talking to Joey and asks him a question that is both funny and a little too accurate: “Let me ask you one question. Do your friends ever have a conversation and you just nod along even though you’re not really sure what they’re talking about?” Joey, of course, immediately zones out. Not metaphorically. Not politely. He disappears into that wonderful Joey place where the mouth stays closed, the face stays agreeable, and the brain has clearly left the building. That was me the first few times I started hearing people talk about MCP. Not once. Not twice. Everywhere. MCP this. MCP server that. MCP is the future of agents. MCP is the USB-C of AI. MCP is how models connect to tools. MCP is the protocol that will make agentic AI real. MCP is the standard. MCP is the integration layer. MCP is the thing everyone apparently understood already, except somehow nobody had bothered to send me the memo. So I did what any responsible technology professional does in that situation. I nodded thoughtfully. The next thing I did was call my son, who is a Data Scientist, and ask him what MCP actually was. After listening to his explanation, I had the uncomfortable realization that he knew more about it than I did, which, naturally, did not feel great. That was just my ego talking, of course. He is way smarter than me. Then I went away and tried to figure out whether MCP was actually important or whether it was just another acronym that had wandered into the AI conversation wearing a conference badge. And that brings me to the other sitcom line that kept popping into my head while I was trying to explain this to myself. In The Big Bang Theory, there is a scene where a very drunk Penny says, “I think I owe you …splanation,” clearly attempting to say ‘explanation’ while her brain and mouth are no longer managed by a ‘unified control plane.’ That is exactly how MCP felt to me at first. I did not need another acronym. I needed a …splanation. A real one. Preferably in English. Preferably without requiring a PhD in distributed systems, three browser tabs of developer documentation, and someone on YouTube drawing boxes and arrows while saying “obviously” before explaining the least obvious thing I had heard all week. So this article is my attempt at that …splanation. After spending time researching MCP, I think it is important. More importantly, I think it is important in a very practical way. It is not the kind of important that requires everyone to become an AI researcher, read white papers at midnight, or pretend that “agentic workflow orchestration” is something normal people say at dinner. MCP matters because AI is moving from something that talks to something that can actually do work, and doing real work requires access to real systems. That is the part worth slowing down for. Most people first experienced modern AI as an LLM chat bot window. You typed something in, and the model responded. Sometimes the answer was impressive. Sometimes it was useful. Sometimes it was wrong with the confidence of a man giving directions in a city he has never visited. But the basic pattern was easy to understand. You asked a question. The LLM answered. That was the product experience. The problem is that most real work does not happen inside a blank chat box. Real work lives in messy places. It lives in documents, calendars, databases, code repositories, CRM systems, ticketing tools, emails, Slack messages, service logs, storage platforms, cloud consoles, spreadsheets, procurement systems, and all the other places where business reality hides after the meeting ends. That is why the first wave of AI, as magical as it felt, was also strangely trapped. A model could write a beautiful summary of a business problem, but unless you gave it the actual business context, it was still guessing. An LLM is not programmed to say “Sorry, I don’t know.” So it makes stuff up with proper grammar and punctuation. It could explain how to troubleshoot an issue, but unless it could inspect the logs, check the configuration, or look at the environment, it was still operating from theory. It could tell you how to prepare for a customer meeting, but unless it could see the account history, the open opportunities, the support cases, the renewal status, and the meeting notes from last quarter, it was basically giving you a very articulate horoscope. MCP is one of the attempts to fix that. MCP stands for Model Context Protocol. The name sounds like it was assembled by people who are very good at distributed systems and very bad at naming things for humans, but the words are actually useful. “Model” refers to the AI model. “Context” refers to the information and tools the model needs in order to be useful. “Protocol” means a standard way for systems to communicate. In plain English, MCP is a standard way for AI applications to connect to external tools and data sources. That may sound boring, but boring is often where the real technology changes happen. Nobody gets a standing ovation for plumbing until the plumbing stops working. Nobody thinks about electrical standards when they plug in a night light. Nobody wants to understand every detail of networking just to open a website. Standards become invisible when they succeed, and that invisibility is exactly why they matter. The analogy people use is that MCP is like USB-C for AI. I know that analogy is already dangerously close to becoming a bumper sticker, but it works well enough if we do not abuse it. USB-C did not make your laptop smarter. It did not make your monitor more creative. It did not make your phone more emotionally available, although at this point I would appreciate it if mine at least tried. What USB-C did was standardize connection. Instead of every device requiring its own special cable, adapter, dongle, ritual, and small sacrifice to the drawer of dead electronics, USB-C created a common interface. MCP is trying to do something similar for AI. It gives AI applications a common way to connect to the tools and data they need. The model does not need to know the internal details of every application. The application does not need to build a completely different integration for every model. MCP creates a shared language in the middle. That middle layer is what matters. Without something like MCP, the AI world runs into what technical people call the N-by-M problem. Katie Baker wrote about it last year: NxM Problem If you have ten AI applications and ten systems they need to connect to, you do not want one hundred custom integrations. If you have fifty AI applications and two hundred systems, you definitely do not want ten thousand custom integrations, unless your business model is selling painkillers to integration teams. The better model is not N times M. It is closer to N plus M. Each AI application learns how to speak the protocol. Each tool or data source exposes itself through the protocol. Once both sides understand the same standard, the number of custom connections drops dramatically. This is the point where MCP starts to become more than an AI developer convenience. It starts to look like infrastructure. To understand how it works, you do not need to become a protocol engineer. You just need to understand three roles: the host, the client, and the server. The host is the AI application the user interacts with. That could be Claude Desktop, ChatGPT, Cursor, Visual Studio Code, or an internal enterprise assistant with a name like Atlas, Navigator, Compass, or whatever else the branding team selected after eliminating “Dave.” The host is where the experience lives. It is where the user types the request, where the model reasons, and where the answer or action comes back. The client lives inside the host and manages the connection to an MCP server. You can think of it as the part of the application that knows how to speak MCP on behalf of the model. It handles the conversation between the AI application and the external capability. The server is the wrapper around a data source. There might be an MCP server for GitHub, another for Slack, another for a database, another for a filesystem, another for a CRM, another for a cloud service, and eventually one for every system that vendors decide must now be described as “AI-ready” in a press release. The server’s job is to expose what it can provide in a way the AI application can understand. It might say, in effect, “Here are the documents I can make available. Here are the actions I support. Here is the format you need to use if you want to call one of those actions. Here are the permissions required. Here is the result you can expect back.” That is where the value appears. The AI application does not need to understand every internal detail of GitHub, Slack, Salesforce, Postgres, Kubernetes, or your company’s deeply loved but spiritually exhausted internal ServiceNOW ticketing system. It needs a standard way to discover and use the capabilities exposed by those systems. MCP gives it that standard way. The protocol itself is built around a few core ideas that are easier to understand than the terminology makes them sound. MCP servers can expose tools, resources, and prompts. Tools are actions the model can ask to perform. A tool might search a database, send a Slack message, create a support ticket, run a test, update a CRM record, query an API, or retrieve the status of a system. Tools are where the AI starts moving from “I can answer your question” to “I can help complete the task.” Resources are information the model can read. These could be files, documents, schemas, database records, logs, API responses, or other pieces of context. Resources matter because AI without context is mostly a very confident intern on the first day of work. It may be talented, it may be fast, and it may be enthusiastic, but it does not know where anything is. Prompts are reusable instructions or workflows. That sounds small, but it is not. In business, consistency matters. You may not want every user inventing their own version of “analyze this account,” “review this code,” “summarize this incident,” or “prepare this forecast update.” A prompt can define how a model should approach a task, what standards it should follow, what inputs it should consider, and what kind of output is expected. Tools let the model act. Resources give the model context. Prompts help shape the model’s behavior. That combination is what makes MCP useful. Let’s make this practical. Suppose you ask an AI assistant to help prepare you for a customer meeting. Without access to your systems, the assistant can give you a generic meeting prep template. It can tell you to understand the customer’s goals, review previous discussions, identify risks, prepare discovery questions, and align to business outcomes. None of that is wrong. It is also not especially magical. It is the kind of advice that sounds helpful until you realize it could apply to almost any meeting with almost any customer in almost any industry. Now imagine that same assistant has controlled access to the right systems through MCP servers. It can read the meeting notes from prior briefings, pull the current opportunity data, review support tickets, check the renewal timeline, inspect open technical issues, summarize the customer’s stated initiatives, and identify where the account team may be telling itself a story that is more optimistic than the facts support. It can then generate a briefing that is not generic at all. It is specific, grounded, and useful. That is the difference between AI as a writing assistant and AI as a work assistant. This is why MCP keeps showing up in conversations about agents. An agent is not just a chatbot with a better title. An agent is expected to reason through a goal, choose tools, gather information, take steps, observe results, and continue until the task is complete or until it needs human help. That requires a standard way to connect reasoning to action. MCP is one of the strongest candidates for that standard layer. This is also where the MCP conversation stops being abstract for anyone running Everpure Fusion. It is one thing to say that MCP allows AI agents to connect to enterprise systems. That sounds interesting, but it can still feel like one of those technology ideas that lives safely inside a product roadmap, an architecture diagram, or a conference session where the coffee is somehow both expensive and terrible. It becomes much more practical when you look at what Everpure is doing with the Everpure Fusion MCP Server. I can almost guarantee that you will not click the link below, so I read it for you. But that will be in Part 2. I already drafted it, but I want to be respectful of your time. Not all of my readers are Everpure customers (yet). So that is my MCP “…splanation,” at least the Part 1 version. MCP is not the robot, and it is not the magical brain that suddenly makes every workflow intelligent. It is the standard connection layer that helps AI move from “I can answer your question” to “I can interact with the systems where your work actually happens.” That may not sound glamorous, but neither does plumbing, electricity, networking, or storage until something important depends on it. And that is why MCP matters. Because the next phase of AI will not be defined only by which model sounds the smartest in a chat window. It will be defined by how safely, consistently, and usefully those models can connect to real tools, real data, and real workflows. In Part 2, I will bring this closer to home and look at what this means for Everpure Fusion, because once AI starts needing context from infrastructure, the way we manage that infrastructure starts to matter a lot more. Appreciate you reading. Dmitry Gorbatov © 2025 Dmitry Gorbatov | #dmitrywashereSOF Week 2026
SOF Week 2026 May 18-21 Tampa, Florida SOF Week brings the international Special Operations community together for one focused week of collaboration, learning, and capability development. Jointly supported by U.S. Special Operations Command and the Global SOF Foundation, the event serves as the central gathering point for SOF Operators, government leaders, and industry partners working to advance the mission. At its core, SOF Week is about connection and alignment. It provides a trusted environment where operational requirements, emerging technologies, and strategic priorities come together in one place. Through briefings, demonstrations, exhibits, and networking, the event accelerates conversations that directly impact capability development and mission success. The purpose of SOF Week is simple: strengthen the global SOF enterprise. By fostering collaboration across commands, agencies, allies, and industry, the event helps ensure the right capabilities reach the right operators at the right time. Click here for more details and to register!
