Registry Descriptions Go Stale Unevenly: An 89-Day Measurement of Model Context Protocol Drift, and Why Drift-Ranked Re-Auditing Under-Covers It

Imagine the internet as a giant, bustling marketplace where computers (called "agents") go to find tools to help them do their jobs. To make this easier, there's a public "phone book" called the Model Context Protocol (MCP) registry. In this phone book, every tool has a little card with a description telling you what it does. Recently, security experts started checking these cards to make sure they aren't lying or dangerous. They take a snapshot of the phone book, read the cards, and say, "This one is safe," or "This one is sketchy."

But here's the catch: phone books in the real world get updated all the time. If you read a description today, is it still the same description tomorrow? Or did the owner sneakily change the text while you weren't looking? This paper asks a simple but vital question: How long does a security check on a description actually stay valid before the description itself changes? It's not about whether the tool inside is dangerous (that's a different story); it's about whether the text the security guard read is still the text the tool is currently showing. If the text changes, the old security check might be looking at a ghost, not the real thing.

---

The 89-Day Mystery: When Phone Books Go Stale

Think of the MCP registry like a massive, living library where new books are added every few hours, and existing books get their covers rewritten constantly. A researcher decided to play a game of "spot the difference" with this library. They didn't just take one photo; they took 120 snapshots over 88.6 days (roughly three months), watching the library grow from about 3,500 books to nearly 19,000. Their goal was to see how fast the "blur" of change happens and whether security guards could predict who would change their cover next.

The Big Surprise: The "Busy Minority" and the "Silent Majority"

The researcher found something fascinating about who changes their descriptions. Imagine a classroom of 19,000 students. If you asked, "Who changed their outfit today?" you might expect half the class to have done it. But in this library, 75% of the servers (the "students") never changed their description at all during the entire 89 days. They were as stable as a rock.

However, the changes that did happen were incredibly concentrated. It wasn't a little bit of change from everyone; it was a massive amount of change from just a few. The top 5% of the most active servers were responsible for 61% of all the changes. It's like if 5% of the students in a school were responsible for 61% of the graffiti on the walls. The rest of the school was just sitting there, unchanged.

The "Crystal Ball" That Cracked

Security teams often try to save time by only re-checking the servers that have a history of changing. The logic goes: "If you changed your description yesterday, you're likely to change it again today. Let's just check the 'frequent flyers'."

The researcher tested this idea. They tried to predict the future by ranking servers based on their past changes. They found that while this method was somewhat better than guessing randomly, it was a terrible strategy for catching description changes.

• If they spent their budget checking the top 5% of servers with the most history, they only caught about 20% of the servers that actually changed their descriptions in the next period.
• Worse, this method was completely blind to new arrivals. Since new servers have no history, they can't be ranked. But the researcher found that new servers are exactly where the most description changes happen. By only looking at the "old hands," the security guards were missing the brand-new kids on the block who were changing their covers the most.

The paper argues that trying to predict who will change based on who changed before is like trying to predict the weather by only looking at the clouds that were there yesterday. It misses the new storm clouds rolling in.

The "Simple Math" Trap

There was another trap the researcher uncovered. If you look at how many changes happen in a single day and just multiply that number by 30 (to guess what happens in a month), you get a wildly wrong answer.

• The Simple Guess: If 1.5% of servers change every day, you might think that by day 30, about 36% of the servers would have changed.
• The Reality: When they actually measured it, only about 12% of the servers had changed by day 30.

Why the difference? The simple math assumes that every change hits a different server. But in reality, the same few servers keep changing over and over. It's like a single person changing their shirt 10 times a day; counting the shirts doesn't mean 10 different people changed their clothes. The "shelf life" of a description is actually much longer than the simple math suggests, but the "shelf life" of a specific security finding is tricky because the text can vanish and reappear.

The Real Solution: Check the Fingerprint, Not the History

So, if we can't predict who will change, how do we keep the library safe? The researcher proposes a simple, two-part rule that works much better than guessing:

1. The Fingerprint Rule (Content-Binding): Instead of guessing who will change, just check the "fingerprint" (a digital hash) of the description. If the fingerprint changes even a tiny bit, the security check is instantly void. You don't need to know who changed it; you just need to know the text is different. This catches about 20 changes a day automatically.
2. The Sweep: For the new servers and the ones that don't change often, just do a full sweep of the whole library every week or month.

This approach is like a security guard who doesn't try to guess which thief will strike next. Instead, they have a scanner that beeps the moment a book's cover is swapped, and they do a full walk-through of the aisles once a week to make sure no new books slipped in.

A Hidden Glitch: The "Born-Stale" Verdict

Finally, the researcher peeked behind the curtain at their own security scanner. They found a sneaky problem: sometimes, the scanner was checking a description after the library had already updated it, but the scanner didn't know. It was like a guard reading a menu from 10 minutes ago while the chef had already changed the soup. About half of the "stale" checks they found were because the scanner was looking at old data before it even started its job. This "lag" meant some verdicts were wrong from the very moment they were born, not just because they got old later.

The Takeaway

The main lesson here isn't that the library is chaotic; it's that the library is concentrated. Most things stay the same, but a few things change a lot, and new things change the most. Trying to predict the future by looking at the past is a dead end because it misses the new arrivals. The best way to stay safe isn't to build a crystal ball; it's to build a system that instantly detects when the text changes and has a plan to check the new stuff regularly. It's a reminder that in the digital world, "checking once" is never enough; you have to keep your eyes on the text, not just the history.