FlagThis

Abstract

Security studies of the Model Context Protocol (MCP) ecosystem have grown quickly, and they share a design: each audits a registry at a single point in time. None reports how long the registry descriptions those audits judged stay current - a _necessary_ condition for any description-level finding to still apply, though not a sufficient one: we measure the shelf-life of the audited text, not the validity of a security finding itself, which turns on live tool behavior we do not observe (7.1). We reconstruct 120 observations of the official MCP registry over 88.6 days, covering 19,099 distinct servers as it grew from 3,510 to 18,966. Our central result is a policy one: you cannot keep description-level findings current by re-auditing the servers that drift most. At a top-5% re-audit budget, ranking by prior drift catches only ~20% of the previously-seen servers whose description changes in a held-out window - versus ~27% for descriptor drift overall - and only ~10% of _all_ description changers. The limit is not that description drift is unpredictable - prior description change lifts next-period probability 4.8x (13.8% vs 2.8%) - but that the signal is _exhausted almost immediately_ : only 5.0% of the population has any prior description-change history at all , against 16.4% for descriptors, so a top-5% budget consumes the entire ranking and caps near 20%, and every slot beyond it is filled by tie-break rather than by signal. Roughly half of _all_ description changes then land on new arrivals a history ranking cannot reach by construction (the highest-drift group). The control that fits is content-binding - revalidate the moment a description's hash moves - plus a sized periodic full-catalog sweep for the new arrivals and the tail; a drift-history ranking is at best a partial, blind-to-new-arrivals control. This is scanner hygiene - keeping a description-level auditor's own findings current - not a runtime trust signal for an agent about to invoke a tool.