Grok 4 Upstaged, Browser Wars Reborn, MCP Governance Published

The xAI team launched Grok 4 last Wednesday. But public opinion has now had time to digest the model, and we think it's making less of a splash than even Moonshot AI's launch of Kimi K2: an open-weight model out of China.

Grok 4 looks great on paper. It blows the other frontier models out of the water on some major benchmarks. Its voice mode has less latency than OpenAI's. xAI has spent an absurd amount of money training it.

But it's failing to excel on the reality tests. While there are some positive reviews of it being a strong planner, actual usage by the community is not bearing out, and critiques have started rolling in. LLM aggregator app Yupp reports it is middle of the road at best. Daily usage on OpenRouter has consistently failed to break the top ten, instead settling for a neck to neck race with Kimi K2 around 15th. Elon Musk appears to be out of touch with the realities of software engineering with AI, believing engineers still copy/paste code into chat prompts and demeaning what engineers actually want optimized for their workflows.

While Kimi K2 is not claiming to be a new frontier model, it is suddenly a leading open source model for coding. Moonshot describes it as optimized for coding and "agentic tasks," the latter of which we think is an increasingly smart concept for an LLM to prioritize. You can even use it with Claude Code. The future looks bright for top tier coding LLMs that aren't locked behind an expensive API endpoint: it's only a matter of time until we get a Sonnet-4 quality model with open weights.

At the application layer, the AI web browser wars have started heating up. The Browser Company was first to market with Dia a few weeks ago. Perplexity launched Comet this week. OpenAI is rumored to be launching their browser within a few weeks.

Some sort of AI-enabled browser UX will likely become the world's default before long. We expect to see these players duke it out with leading incumbent Chrome, much like we see Cursor vs. Windsurf (RIP) vs. VS Code in the IDE wars.

One thing we think Perplexity is getting very wrong: a continued lack of regard for cooperating with the web ecosystem. CEO Aravind Srinivas puts down MCP and believes the way to AI-ify browsers is to adversarially scrape every website and service, trying to pretend that autonomous agents are the same as human users. That might sort of work while you're a relatively small player like Perplexity. But as soon as you get some traction, website owners will act on these fundamental truths:

1. By default, agents bypass the very systems that prop up the internet economy. Branding, advertising, UI/UX, regulatory compliance: it's all built for humans. Humans in turn - on average - respond with enough commercial activity to justify websites' investment in making the internet great.
2. Bots (agents) tend to abuse API services not designed for them. We see the differences already with systems like CI/CD pipelines, where an agentic flow can easily 10x or 100x the load a previously underutilized process might have.
3. Agents need a rethinking of auth and security paradigms. There is a huge difference between humans acting on behalf of ourselves, versus delegating permissions to someone to ask on behalf of us. It is impossible to treat auth as a one-size-fits-both-humans-and-agents problem.

MCP is the collaborative path forward to an incentive-aligned, healthy web ecosystem. It can play nicely with the new wave of AI-enabled web browsers, if they choose to participate. And if you're still an MCP skeptic, have a read through Speakeasy's extensive take on why you shouldn't be.

Have questions or feedback for the Pulse team? Requests for changes on pulsemcp.com? Ideas for content/collaboration? Join our Discord community.

What's upcoming for MCP?

The core MCP team has published an official plan for how MCP governance will be managed moving forward. The highlights:

→ Everyone involved in MCP stewardship is involved as an individual, not as a company. As people leave their jobs, they retain their status in the community, and no company has a guaranteed spot. While this decision is in line with the narrative that MCP is a community project, it's worth recognizing what a major concession this is for Anthropic: as employees inevitably shuffle employers in the years to come, it's entirely possible that any influence over the protocol walks out the door with this small number of at-will employees.

→ David and Justin, the creators of MCP, will serve as the lead maintainers: BDFLs. This "dictator" model has served many open source communities very well: Linux, Python, Ruby, Rails, Laravel, and many more. And the fact that it's both David and Justin protects us against one of those outlier Matt Mullenweg outcomes.

→ A step below David and Justin are the core maintainers. Currently, employees from Anthropic, Google, OpenAI, Microsoft, AWS form this group. And to round out the MCP steering group, there is one more role: maintainers. These are the people owning various projects within the modelcontextprotocol organization, including yours truly, Tadas, on the MCP registry.

→ There is now a notion of a "SEP" - a Specification Enhancement Proposal - a formalized format and process for how any new changes to the MCP specification will be made. Anyone can write a SEP, but to make its way to the process, it needs to be sponsored by a member of the MCP steering group.

Governance is the major update of the week, and might be a theme of a few more to come. For a more in-the-weeds nugget, check out this work-in-progress PR from Oliver of Anthropic working to AI-ify more of MCP's SDK development. And take a peek at the official MCP blog. There's not much on it yet - but you'll probably see announcement posts and other onboarding-type tutorials make its way here over time. We're still excited about Secure Elicitations and Long-Running Tool Calls from last week - no major updates on those yet.

Featured MCP Work

Chrome Automation (Mon, July 7; #5 overall) MCP Server by @hangwin
→ This MCP server has taken the MCP community by storm, snagging a #5 overall spot in usage. It lets you connect an MCP client like Claude Desktop to your existing Chrome browser. So unlike Playwright, it doesn't just spin up an isolated instance of Chrome. You can use this with whatever accounts you're already logged into. While we don't think it is practical to use for typical browser sessions, it could be an extremely useful alternative to Playwright for app testing, providing a stopgap workflow for some hard-to-use website without an MCP server, or doing dev workflows like inspecting Chrome network requests while debugging or building software.

Headless Terminal (Fri, July 11) MCP Server by Memex
→ Enable your MCP client to run interactive terminal commands. In a world where terminal UI's like Claude Code and Gemini CLI are taking development by the storm, a common meta-need you'll run into is the desire to get your client to see what you're seeing. One of our favorite MCP use cases is to use an MCP server like Playwright to fire up a browser and assess whether a code change had the desired impact on your app. This MCP server from Memex gives you the same capability, except for terminal UI's. Even if you're not engineering a TUI yourself, you can use this for a situation like, "Claude Code, please start another instance of Claude Code and assess why your Hooks configuration isn't working properly."

Database Toolbox (#1 overall) MCP Server by Google
→ One of Google's only two official MCP servers to-date, this server finds itself atop the usage charts, probably due to a recent marketing push from Google. Database interactions have long been a killer MCP use case, and this server tries to thread an interesting needle: use a tools.yaml declaration to preconfigure exactly what tools (queries) you want your server to surface. It offers a control plane for ensuring that the tools you hand to your agent are mapped exactly to the database in the way you want, with appropriate limitations and ergonomics in place.

Director (Mon, July 14) official MCP Client
→ "Unify your MCP usage" gateway solutions have been launching regularly, but this one stands out for its polish and thoughtful vision. Use it today to solve the MCP server configuration hell you might be going through, jumping across apps. And we hope to see the team evolve this solution to being something that straddles the line between allowing MCP clients to manage client-specific MCP configs themselves, but carve out the cross-cutting configs like auth and API keys in a single place.

Drop-in MCP OAuth by Scalekit
→ The Scalekit team has been hard at work delivering an auth solution for MCP server builders that is easy to drop-in: use it to easily integrate auth into your remote MCP server, without having to replace your IdP (you can keep Auth0, Firebase, etc. around). Scalekit is delivering "managed MCP auth" here at the bleeding edge of the MCP spec, so you can rely on them to be an abstraction layer over the more established IdPs whose bare infrastructure would require you to roll (and maintain) more of your own MCP-compliant code. Hear more about them on a recent episode of The Context.

Browse all 300+ clients we've cataloged. See the most popular servers this week and other recently released servers.

A Few Good Links

→ Grok has faced a slew of PR problems stretching beyond its lukewarm reception to Grok 4. In the days leading up to the launch, @grok went off the rails, adopting a Hitler-esque persona across X.com. After the Grok 4 launch, there was another mini-controversy where Grok appeared to use "from:elonmusk" searches as references for questions that start with "what do you think about…". To top it all off, researchers sounded off on xAI's lack of documented safety testing, "If xAI is going to be a frontier AI developer, they should act like one." All in all, it is very hard to even begin to consider integrating Grok into real workflows when it is now clear that these are recurring problems, not just one-off incidents.

→ OpenAI was meant to release their first open-weight model last week, but it was delayed due to "safety testing." Could be, or maybe OpenAI just found itself intimidated by the surprise reception of Kimi K2. Maybe Elon will make good on his promise to open source Grok 3 sometime soon as well? We're not holding our breath.

→ Windsurf went through a wild few days: their acquisition deal with OpenAI fell through, so Google swooped in with a $2.4b consolation prize for some key personnel. This left everyone else behind to continue Windsurf as an independent business. Social media backlash ensued, with Windsurf leadership taking heavy criticism for leaving their team in a lurch. But then Cognition, the creators of Devin, came in and acquired the remainder of Windsurf, "with 100% of Windsurf employees participating financially." Quite the rollercoaster, but ultimately only likely to impact the enterprise world where Devin and Windsurf have the most market penetration.

→ Cline, the agentic coding VS Code extension, offers a thoughtful contrarian take on all that controversy over Cursor's pricing last week: "You should have confidence that when you spend $20 on frontier models, you're getting $20 in frontier model intelligence." Although they have a point - there's merit to guaranteeing yourself a consistent, capability-maximized experience - our counter-take is that the VC-subsidized compute time is just too good to pass up right now. If you're keeping up with trends and know where the good deals are (hint: Claude Max), we think you'll come out ahead. You're not really risking "getting used to" spending too much either: by the time the VC cash runs dry, those open-weight models will be as good as today's frontier models.

→ Jack Dorsey announced that Goose, the local AI agent, is getting a renewed injection: a team of engineers and designers, and a grant program for contributors all over the world. Goose was one of the earliest products to adopt MCP, and their new roadmap promises a further doubling down on pushing along the path MCP is paving.

→ Kent Dodds of JavaScript education fame has been hard at work digging deep into the MCP ecosystem. He's making a bet that MCP will form the foundation of UI/UX interaction in the future (we agree), and putting out timely workshops on topics like MCP fundamentals and Advanced MCP Features. In an ecosystem still working out its documentation and best practices, this kind of structured education is a very helpful anchor for folks ramping up; and Kent is doing a great job keeping up with the latest in MCP.

→ One of Kent's long-term hypotheses is the existence of an MCP Search Engine that he's been writing recently about. Although we're not totally sold on the specifics of the vision, others are. In particular: Smithery, one of the earliest players in the MCP space, recently brought onboard a new cofounder, Anirudh, in their mission to build exactly this. Regardless of whether or not we think there will be one MCP Search Engine to rule them all, we absolutely do need some specification work to solve the more fundamental problem of MCP discovery. If you're keen to help, we suggest you start reading here, and then build off of the MCP registry's server.json shape to start a SEP on bringing server.json into .well-known URI's.

→ Hugging Face wrote up a nice breakdown of how they went about building and deploying their remote MCP server. For those unfamiliar with the options, it can be confusing to wade through the nuances of the Streamable HTTP transport, the options you have to work with, and some gotcha's along the way: worth a read if you're planning to put your server out on the web.

→ The second MCP Developers Summit was just announced: it's happening in London on October 2. If you loved the first one in San Francisco in May, you won't want to miss the European version. Sign up for early bird tickets, or submit a talk proposal by August 17.

Cheers,
Mike and Tadas