REDACTED PUBLIC COPY (13 October 2026). Names, internal file paths and internal tool names are replaced; nothing else is changed. The sha256 values below refer to the unredacted originals, available on request from seo@blotato.com. # Study #7 pre-registration v3.4: are new social media MCP servers outpacing MCP overall? (2026-10-12) **v3 (after internal review, NO-SHIP on mechanical holes, "the design is sound"):** the procedure is now locked, not just the prose. `collect_trend.py`, `analyze_trend.py` (every gate computed in code) and study #6's collect.py (source of the post-filter regexes) are hashed in `LOCK.log` together with this file. G4 is symmetric (precision on both numerator and denominator) and checks the latest quarter; D1 has a volume floor; completeness, owner cap, G5 and UTC are defined. v2 kept as `PREREG-v2.md`. **v3.1 = amendment A1** (internal review, text-vs-code mismatches; logged in `LOCK.log` before D was collected or any share computed). Note: collection of raw responses began 17:36:35 CT on the v2-shaped collector saved 17:36:21 CT (unchanged since; its hash is logged with v3). Raw collection computes nothing. **v3.2 = amendment A2 (2026-10-13, logged in `LOCK.log` before any npm download was pulled and before any D1 or D2 figure was computed):** the D2 npm search `text=keywords:mcp ` did not filter by term (every term reported total 79,385, all packages tagged mcp) and stopped at the top 2,000 by a relevance score that tracks downloads, so the cohort was truncated and tilted toward packages popular now. D2's cohort search is now `collect_npm_a2.py`: packages tagged both `mcp` and the term, every page pulled, collected == total proven per tag. The capped pull is kept in `raw/npm_capped_v3/` and never computed. **v3.4 = amendments A3 and A4 (2026-10-13, both logged in `LOCK.log` before any sample was drawn and before any N, share or demand figure was computed).** A3: `recheck_cells.py` stopped paging on a short page and truncated re-pulls; fixed to page like the collector, defective run quarantined. A4 (the study lead's decision after the stop rule fired): the s4 stop rule counts the repos actually missing from still-incomplete cells, not those cells' whole totals. After the one re-pull, 14 D cells in P2 stayed 3-5 short on both pulls with the same ids (GitHub's `total_count` includes repos its search never returns): 54 missing repos (0.024% of raw D P2) inside cells totalling 8,437 (3.7%). The 54 can lower D P2 by at most 0.024%, so they can raise S(P2) by at most that much, against G4's 1.10 bar. Written BEFORE any trend was computed. v1 (`PREREG-v1.md`, sha256 e8a4a828...) went NO-SHIP (RETHINK ANGLE) at the internal review: outcome B published a "no" as a GO, M2 was not a gate, the precision trigger was noise, D2 selected on the outcome, the GitHub 1,000-result cap and mass creators were unhandled, M4 maintenance-by-cohort was mechanical, and there was no ICP-fit test. the study lead then chose (2026-10-12): **hardened test; a pass ships as a dated section on study #6, a fail is SKIPPED; no standalone page.** Exposures before this version, none of them a study #7 measure, are logged in `LOCK.log` (ecosystem-wide registry counts from prior art; vendor agent-posting figures from the AI baseline). ## 1. The question and the claim **Among GitHub repositories created each month, is the share that are social media MCP servers rising (social outpacing MCP overall), and does demand corroborate it?** The claim is about **MCP servers on GitHub**, never about "AI agents running social media" in general (agents can also use Skills, CLIs or hosted servers, which this does not measure; that substitution is disclosed). ## 2. ICP-fit test (Step 0) - **(a) Who:** builders choosing a social media MCP server from study #6's list. - **(b) Decision:** weak, stated honestly: whether the options for social media are still multiplying faster than MCP as a whole (a moving market, re-check before committing) or settling. This is not strong enough for a standalone page, which is why a pass ships as a section of study #6, where it dates and contextualizes that study's snapshot. - **(c) Why link:** prior art finds no social-specific MCP series (all tallies are snapshots; `prior-art.md`, `ai-baseline/SUMMARY.md`). A dated, pre-registered series is citable. - **(d) Blotato tie:** none in the finding. Blotato's server is registry-only with no repo, so it is not in any GitHub measure. - **Builder sentence (section intro):** "Study #6 is a snapshot. This shows whether new social media MCP servers on GitHub are appearing faster than MCP servers in general, measured by rules fixed before the data was read." ## 3. Periods P1 = 2025-10-01..2026-03-31. P2 = 2026-04-01..2026-09-30. October 2026 excluded (partial). Quarters for G2: 2025-Q1..2026-Q3. ## 4. Collection (identical method for numerator and denominator) - **The code is the definition.** `collect_trend.py` (query set, split rule, D2 cohort search) and `analyze_trend.py` (post-filter, completeness, owner cap, samples, bootstrap, gates) are the only definitions of the procedure. Their sha256, and that of study #6's collect.py (regexes `PLATFORMS_A3`, `GENERIC_A3`, `X_FALSE_STEMS` and its X rule, copied verbatim into `analyze_trend.py`), are logged before any trend is computed. Any later change is logged in `LOCK.log` as an amendment with its reason and new hash BEFORE the changed step runs. All windows are UTC. - **Numerator N:** repos (`fork:false`, no star floor) whose name, description or topics match a platform term AND `mcp`. Terms = study #6's collect.py `GH_TERMS`, `X_NAME_QUERIES`, the A2 generic queries and the A3 queries (listed in `collect_trend.py`). Post-filter: study #6's `PLATFORMS_A3` regex or its `GENERIC_A3` regex must match name+description+topics; study #6's X false-stem rule applies (a false stem in the repo NAME with no twitter/tweet anywhere drops the X match only). Union by repo id. - **Denominator D:** repos matching `mcp in:name,description,topics fork:false`, listed by id. - **Search-cap rule:** every query cell is listed by id. Any cell over 1,000 results is split by halving its time window (down to 1 hour) until each cell is under 1,000. A cell is complete when collected ids are within max(2, 0.5% of `total_count`) of `total_count`; an incomplete cell is re-pulled once and is complete if the re-pull meets the same tolerance. The study STOPS (the study lead told) if the repos missing from still-incomplete cells (`total_count` minus collected ids, summed) exceed 1% of raw N in any quarter (2025-Q1..2026-Q3) or of raw D in P1 or P2. (A4, 2026-10-13: as locked in v3.2 the rule summed the incomplete cells' whole `total_count`; that version fired on D P2 at 8,437 of 225,297 while 54 repos were missing. Both figures are disclosed.) - **Symmetry:** N is kept only where its name, description or topics contain `mcp` (D's text rule). For the share S (G4, G5), N is further restricted to repos present in collected D (GitHub's token search can miss names like `fastmcp-*`, and some N queries are name- or topic-only); the per-month count excluded is reported. G0-G2 use full N (D is not collected for 2025-Q1..Q3). - **Owner cap:** an owner counts once per month in N if any of their repos created that month matches (same rule for D). The owner's earliest-created matching repo that month is its representative for sampling. Gates use capped counts; raw counts are reported alongside. - `created_at` before 2024-11-25 never enters the windows. Topics added late (deflating recent months) and deleted repos are disclosed; the share measure cancels what hits N and D alike. ## 5. Precision samples (N and D) - 150 representatives drawn at random from P1's capped N and 150 from P2's, stratified by match stratum: each single platform, "multi" (2+ platforms) and "generic" (proportional allocation, largest remainder, seed 20261012). - Each classified from its README and manifest against study #6's inclusion rule (MCP server code; a tool acts on a named platform's accounts or content). Unreadable = no. classifiers, spot-check of 20%. - A second sample of 100 representatives per period from capped D, classified yes/no for "contains MCP server or client code" (unreadable = no). R_d = d2 / d1. - R_p = p2 / p1. Joint bootstrap (10,000 resamples of all four samples, seed 20261012). G1 uses the lower 2.5% bound of R_p; G4 uses the lower 2.5% bound of R_p / R_d. - Implied bar, stated before data: at roughly 44% precision the R_p lower bound may sit well below 1, so G1 can need a raw rise well above 1.25x. A SKIP is the cost of that conservatism. - Descriptive only, from the N sample: share of true servers that publish (study #6 capability definition), P1 vs P2, always with its 95% interval and no directional wording unless the interval of the difference excludes zero. Never a gate. ## 6. Demand signals - **D1 search (Labs `keyword_overview`, US, one call).** Set, fixed: `social media mcp`, `social media mcp server`, `mcp social media`, `twitter mcp`, `x mcp server`, `facebook mcp`, `instagram mcp`, `instagram mcp server`, `threads mcp`, `tiktok mcp`, `pinterest mcp`, `bluesky mcp`, `reddit mcp`, `post to instagram with claude`, `post to linkedin with claude`, `claude post to twitter`, `chatgpt post to instagram`, `chatgpt post to linkedin`, `ai agent social media posting`, `automate social media with ai agent`, `social media api for ai agents`. **Dropped as off-construct** (per (internal file)): `linkedin mcp`/`linkedin mcp server` (scraping intent), `youtube mcp`/`youtube mcp server` (transcript intent), and broad `ai agent social media`, `claude social media`, `chatgpt social media posting`. A keyword with any missing month is dropped (conservative). **Floor:** D1 counts only if, after removing the largest keyword, at least 4 keywords remain AND their summed prior-6-month volume is at least 300 (largest = highest 12-month sum). Otherwise D1 is "insufficient": it cannot satisfy G3 and cannot block it. Latest 6 months vs prior 6 of whatever 12 Labs returns (window shift disclosed). `mcp server` is pulled as context: D1 relative to it is reported, never gated. - **D2 npm downloads, independent cohort.** Packages tagged both `mcp` and a term by npm registry search (`registry.npmjs.org/-/v1/search`, `text=keywords:mcp keywords:`, tags = `collect_trend.py` NPM_TERMS with spaces as hyphens; amendment A2, `collect_npm_a2.py`, every tag collected in full with collected == total), with package `time.created` before 2025-10-01, whose name, description or keywords contain `mcp` and match the platform or generic regex. Never drawn from study #6 rows. Daily downloads 2025-10-01..2026-09-30 from `api.npmjs.org`. Bot and mirror downloads not separable (disclosed). Hosted servers are invisible to npm, so a shift to hosted servers can depress D2 (known false-fail cause, disclosed). Packages that name a platform without tagging it are outside the cohort (A2 trade-off, disclosed). ## 7. Gates (all must hold for a PASS) - **G0 n:** capped N in P1 >= 30. - **G1 supply up:** capped N P2/P1 x lower bound of R_p >= 1.25. - **G2 not past peak:** capped N in 2026-Q3 >= 2026-Q2, AND >= 0.8x the highest quarter of 2025-Q1..2026-Q2. - **G3 demand:** D1 >= 1.10 with its largest keyword removed, OR D2 >= 1.25 with its largest package (highest P1+P2 downloads) removed. AND D1 (largest keyword removed) is not below 0.80. An insufficient D1 neither passes nor blocks. D2 has no blocking rule (hosted-shift reason). - **G4 outpacing (the question):** S = capped N / capped D summed over the period. S(P2)/S(P1) x lower bound of (R_p / R_d) >= 1.10, AND S in 2026-Q3 >= 0.9 x S in 2026-Q2. - **G5 breadth:** (a) the largest stratum (the platform or "generic" stratum whose only-match repos, when removed, lower P2 capped N the most) is removed: repos whose only match is that stratum are dropped from N, R_p is recomputed without that stratum's sample items, and G1 and G4 must still pass. (b) For G1, the P2 month with the highest capped N is removed and P2 is compared on its per-month mean; for G4, the P2 month with the highest S is removed and S(P2) is recomputed over the remaining five months (ratio test only; the latest-quarter check is not repeated). Both must still pass. ## 8. Outcomes - **PASS (all gates):** ships as a dated section on study #6, heading "Are new social media MCP servers growing faster than MCP overall?": one chart (S by month), one sentence, one frame line ("share of new GitHub repositories mentioning MCP, no star floor, keyword-matched and precision-adjusted"). **No absolute social-server count is printed** (it would collide with study #6's frame). The gate table, PREREG.md, LOCK.log and the scripts are downloads, and the Method line: "This analysis was pre-registered on 2026-10-12 to publish only if every gate passed." Study #6 takes an `updatedDate`, never a pubDate bump. - **ANY gate fails:** Task 5 SKIPPED. the study lead gets the gate table and the series. Nothing is published (the study lead's decision 2026-10-12); the publish-only-if-pass design is recorded here. - No "rise" or "AI agents" wording on any surface. Counts carry denominators; "on GitHub" travels with every figure. ## 9. Blotato and conflict Blotato sells a hosted social media MCP server, so a pass flatters it. Handling: gates fixed and hashed before data; Blotato is in no GitHub measure; the section carries "Blotato publishes this study and sells a hosted social media MCP server"; the pre-registration and hashes are public. ## 10. Desk-only and endpoint safety Hosts allowed: `api.github.com`, `registry.modelcontextprotocol.io`, `registry.npmjs.org`, `api.npmjs.org`, DataForSEO via MCP. No MCP endpoint, registry remote or package is contacted or run. Study #6's hard-deny list applies.