DEV Community: Roee Tsur

1 of 4,356 public MCP servers is ready for the 2026-07-28 spec

Roee Tsur — Sun, 12 Jul 2026 12:55:36 +0000

One. Out of 4,356 remote MCP servers I could openly probe in the official registry, exactly one passes all three checks the 2026-07-28 spec makes mandatory. 90.8% do not yet. Here is what that means, and just as importantly, what it does not.

First, what it does not mean. Nothing breaks on July 28. That date is when the spec text gets published, not a switch that flips. Old protocol versions keep negotiating, deprecated features stick around for at least a year, and every server that works today keeps working. So this is not a countdown to an outage. It is a snapshot of how far the ecosystem has moved toward the new stateless core, and the honest answer is that it has barely started. Given the spec is not even generally available yet, and only SDK betas exist, that is exactly what you would expect. Think of it as the "before" picture.

What I did

I built a small zero-install tool called mcp-spec-check that black-box-probes a live MCP endpoint and reports whether it is ready for the 2026-07-28 release. Then I pointed it at the whole official registry: every active server's latest version, 16,186 entries, which flattened and deduplicated down to 7,850 unique remote URLs across 5,549 hosts. No source access, just wire behavior.

Of those 7,850 targets, 7,849 returned a verdict (one exceeded the time budget):

access	count	share
open	4,356	55.5%
auth-walled	2,008	25.6%
not an MCP endpoint	977	12.4%
unreachable	508	6.5%

Among the 4,356 open servers, readiness for 2026-07-28 breaks down as 1 ready, 3,956 not ready (90.8%), and 399 (9.2%) too ambiguous to call. The three required checks are the mandatory behavior changes: implement server/discover in place of the old initialize handshake, validate the new Mcp-Method routing header, and work without a protocol-level session. Most servers miss on the routing header and on discover.

The version picture

This is the part I find most telling. For each open server I recorded the newest protocol version it will actually demonstrate speaking, not just claim. The current release, 2025-11-25, is the most common by far at 1,922 servers. A long tail still negotiates versions from 2024 and early 2025. Exactly 5 servers demonstrably speak 2026-07-28.

I almost got this number badly wrong, which is worth a word on method. An early cut counted any stateless server as "speaks 2026-07-28," and that inflated the count to 2,513. But statelessness proves nothing on its own: 2,511 of those were old servers, some still on 2024-11-05, that happen to be stateless and tolerantly ignore the new fields. The real signal is whether a server does something only a 2026-07-28 server does, like advertising the version through server/discover or enforcing the new routing header. Corrected, it is 5.

One number nobody else has

Of the 2,008 auth-walled servers, 1,524 (75.9%) publish their OAuth protected-resource metadata at the standard well-known path, which is readable without credentials. So on the authorization hardening front, the auth-walled population is much further along than the open population is on the stateless core. That is the one readiness signal you can measure through an auth wall, and I have not seen it reported anywhere else.

How I kept it honest

Two things I was careful about. Auth walls are not failures: a 401 means a server needs credentials, not that it is broken, so those servers get classified, not graded. And when a server answers ambiguously, for example it replies to the legacy handshake but rejects the new-style probes with a nonstandard error, I mark the check inconclusive rather than guessing. Publishing how much I could not assess is more useful than false precision. Every percentage in the full writeup sits next to its denominator, and because the registry is concentrated (the single largest host is 15.5% of all targets) every headline number is also reported host-collapsed, so you can see it is not an artifact of one big gateway.

For a concrete proof that the new core is shippable today: GitHub's MCP server is auth-walled, publishes RFC 9728 metadata, and passes the required checks when probed with a token.

Check your own server

If you run an MCP server, you can check it in about thirty seconds:

npx mcp-spec-check https://your-server.com/mcp

You get a one-line verdict, ready for 2026-07-28: YES / NO / UNKNOWN, plus per-check detail and links to the migration docs. The full writeup, with every denominator, the host-collapsed view, and the raw aggregate you can cite, is in the repo: github.com/Roee-Tsur/mcp-spec-check.

I would rather you catch a gap now, with months of runway, than after the clients you care about have already moved on.

SEO with Claude: Building an AI-Driven Analytics and PR Pipeline

Roee Tsur — Thu, 28 May 2026 21:33:27 +0000

SEO is often treated as a dark art by developers. But fundamentally, it is really just data analysis and content iteration.

For our last product, we did SEO the traditional way, and it took a full year to start seeing a spike in impressions. For our new launch, we wanted an engineering solution to a marketing problem. We decided to automate the foundational SEO work using Claude.

Here is a breakdown of the automated pipeline we built to handle our SEO.

The Architecture: Two Distinct Routines

We did not want an AI making unchecked changes to our repository every day. To maintain stability and human oversight, we separated our AI workflow into two distinct routines for data analysis and code execution.

1. The Daily Cron: Data Analysis

Every day at 9:00 AM, a routine kicks off to pull our latest search data.

Claude ingests the raw metrics like impressions, clicks, CTR, and position changes. The output is a digested daily SEO report. Instead of building custom dashboards or manually querying APIs, I get a plain-text summary of our search performance to review with my morning coffee.

2. The Weekly Cron: The Automated Pull Request

Data is useless without action. Every Friday at 10:30 AM, the second routine runs.

Claude synthesizes the daily reports from the past week and drafts actionable SEO improvements. It might update meta tags or refine on-page content for better keyword targeting. The output is a fully formatted Pull Request ready for review. The AI acts as a contributor, so my only job is to review the diff and merge the PR.

Why Developers Should Automate the Basics

We are not reinventing the wheel here. Good SEO still requires quality content and solid link building. However, treating SEO as an automated CI/CD process rather than a manual marketing task helped us build a self-improving system.

If you are launching a new project, do not wait a year for the algorithm to notice you. Pipe your data into an LLM, schedule a cron job, and let the AI open the PRs.

What it takes to get approved on the Zoom App Marketplace

Roee Tsur — Wed, 20 May 2026 18:03:55 +0000

We just got Sponja approved on the Zoom App Marketplace after 20 days and 4 rejection rounds. Notes from each round, while it's still fresh.

TL;DR

We just got Sponja approved on the Zoom App Marketplace after 20 days and 4 rejection rounds.
This is what each round actually surfaced:
- reviewer login access
- OAuth scope auditing
- a configuration issue Zoom's testing helped us catch
- listing-level fixes.
Posting our notes while they're fresh in case any of it saves someone else a round.

I want to write this down while it's fresh. Almost nothing I found online prepared me for what the Zoom review team actually checks, and we just came through it the hard way.

Sponja is a post-event intelligence app for Zoom meetings and webinars. The integration was live for our early customers before we submitted to the marketplace, so I walked in thinking "we've been running this in prod for weeks, how bad can the review be." I was wrong about that.

If you're about to submit, or you're in the middle of a review cycle right now, this is what they actually care about.

Round 1: They need to be able to log in (so they can actually use your app)

The first rejection came back with the subject line "Account Credentials - CREATE."

What this means: the review team is going to log into your app and exercise the integration end to end. They need credentials. If your only auth method is "Sign in with Google" or any other federated SSO, they can't create an account on their own, and they will reject you.

Sponja was Google-SSO only at the time. I had to ship a second auth path. We added a separate email and password login flow specifically for the Zoom review team, with their account provisioned manually. It's normal Firebase auth on a dedicated route. The review team uses it.

If I had read this post before submitting, I would have built that flow upfront. It's the lowest-effort thing on this entire list and it removes a full round trip.

Round 2: They test every scope and remove the ones you don't use

This is the round that taught me the most. The reviewer sent this email back:

By following the test plan provided, we have validated the use of scopes and found:

webinar:read:webinar - No calls to fetch webinar details were found.

webinar:read:list_past_participants - No calls to list webinar participants were found.

cloud_recording:read:list_user_recordings - The developer lists recordings by Meeting ID, not by User ID.

cloud_recording:read:meeting_transcript - Although you receive a 'transcript ready' webhook, you never call the API to actually read or download that transcript.

Please remove these scopes at this time to pass the functional portion of this review. If you need these scopes, please expand on your test plan that includes steps to test for them.

Two things to know about this round.

The reviewer instruments every test call against your app and checks it against the scopes you requested. If a scope isn't exercised during their test, you either remove it or write a test plan step that forces them to hit it. There's no arguing. If you want to see how this maps to a real integration, we publish exactly what data Sponja reads from Zoom and what each scope is used for.

The test plan you submit is the whole game. They follow it literally. If your test plan only covers meeting ingestion and not webinar ingestion, you cannot keep the webinar scopes. The fix isn't to push back, it's to write a plan that walks them through every integration path you actually need.

The interesting one for us was cloud_recording:read:meeting_transcript. We had requested it because we ingest transcripts and the scope name says "meeting_transcript." But that scope actually gates a separate endpoint called GetMeetingTranscript, which we don't call. Transcripts come down through the recordings file listing under a different scope. We removed the scope and kept the transcripts. The takeaway: map scopes by endpoint, not by what the scope name sounds like. The granular scopes table at developers.zoom.us is the source of truth.

We expanded the test plan to cover webinars, dropped the unused scope, and resubmitted.

Round 3: When their tests fail, sometimes you really are the bug

The reviewer came back with two screenshots. One showed their Zoom developer dashboard with our API calls erroring out. The other showed our dashboard with their test events stuck in "ingesting" forever.

My first instinct was that their test events just didn't have cloud recording enabled. That would explain the 404s. It was the wrong instinct.

After spending an hour in Cloud Logs and Firestore for that specific team, we found the actual cause. We had recently rotated our Zoom credentials and the dev and prod Zoom Client IDs ended up in the wrong secret slots. Production was verifying webhook signatures against the dev secret. Every signature failed silently. Every event got stuck.

The blast radius was narrow (events that came in during a short window after the rotation), the fix was one secret update, and we added a release-time check so the active environment's secrets get verified before any deploy that touches webhook handling. The bug was real. The catch was also real. Zoom's review process is genuinely thorough.

The portable lesson is: before you hand the marketplace team your test plan, double-check that your dev and prod credentials are in the right slots. The cost of skipping this check is two days of confused back-and-forth with reviewers who can't figure out why your app is broken.

Round 4: The grab bag (you will get nitpicked)

By round 4 they were down to the listing-level stuff:

Not enough images. The screenshots in our listing weren't enough. They want to see the actual experience, not just a single hero shot.
"Redirect Localhost." We had localhost in our production OAuth redirect URI configuration. They flag it as a hardening issue. Remove all localhost and 127.0.0.1 entries from your production OAuth config before submitting.
Some small listing copy fixes.

This round took 24 hours. It's the round where you should expect to be nitpicked and you should not push back. They're doing their job. Fix the things, resubmit, done.

What I'd tell a friend who's about to submit

A few concrete things.

Build the reviewer login path before you submit. Whatever your normal auth is, add a separate email and password login for the review team. Saves you a full round.

Write the test plan from the reviewer's perspective. The reviewer copy-pastes your steps and runs them literally. If you write "trigger a webinar ingestion," and there's no obvious way to do that in your app, they'll skip it and reject the scope. Spell out every click.
Match every requested scope to a specific API call in your test plan. Don't request scopes "just in case." For each scope, your test plan should have a step that causes that scope to be exercised. If you can't write that step, drop the scope. And look the scope up by the endpoint it gates, not by its name.

Audit your prod config before you give them the test plan. Verify dev and prod credentials are where they're supposed to be. Remove localhost from prod OAuth redirects. Make sure your webhook secret matches the right environment. The reviewer will trip on stuff you've been living with for weeks.

Expect 4 rounds, not 1. Plan two to three weeks end to end. The review team is responsive but each round has overhead. If your launch depends on being live by a specific date, start the submission a month out.

Why we did this

Sponja runs on top of Zoom. We use the attendee data to surface the buying-intent signal hiding in your webinar attendance reports, then turn each session into a per-attendee follow-up email grounded in what every person actually did. We can ingest that data through OAuth without being on the marketplace, but the listing is what makes us discoverable to the Zoom user base, what builds trust at the install moment, and what lets us grow beyond hand-shared signup links.

The 20 days were worth it.

If you're building anything on top of Zoom meetings and webinars, this is what we built. If you're in the middle of a marketplace review and any of this would have saved you a round, my DMs are open.