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

arXiv:2608.00997 · cs.SE, cs.CR · Submitted 2026-08-02 · Read on arXiv

Gautam Bharti

cs.SE, cs.CR

Submitted: 2026-08-02

Comments: 13 pages, 1 figure. Dataset and code: Zenodo DOI 10.5281/zenodo.21709945 (CC-BY-4.0); this paper version corresponds to dataset v4, DOI 10.5281/zenodo.21798111. v2 corrects five claims found by re-running the paper against its own deposited artifact; each is itemised in the "Changes in v2" section (p.2). The concentration, survival and targeting-coverage findings are unchanged

License: http://creativecommons.org/licenses/by/4.0/

The gist: Security studies of the Model Context Protocol (MCP) ecosystem share a design: each audits a registry at a single point in time.

Terminology

Abstract

Security studies of the Model Context Protocol (MCP) ecosystem 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 (Sec. 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 unpredictability: the ranking still buys 4x lift. It is that the description surface is sparse - 8.6% of servers ever rewrite one, against 24.8% for descriptors - and that roughly half of all description changes land on new arrivals a history ranking cannot reach, so the same lift buys far less coverage. The control that fits is content-binding - revalidate the moment a description's hash moves - plus a sized periodic full-catalog sweep; a drift-history ranking is at best a partial, blind-to-new-arrivals control. This is scanner hygiene for a description-level auditor, not a runtime trust signal. Of servers observed across at least ten intervals, three-quarters never change, the most active 5% generate 61% of all change events, and only 11.9% of a cohort's descriptors change within 30 days; naive compounding predicts 35.8% at 30 days (73% at 89), a heavy-tail overestimate we use only as a diagnostic. We release the panel, figure generator, and analysis code.

Sources

Related papers