AI’s Peak, Cursor’s Profitability, Where Are The Ads?

Heads up: we'll be taking a week off next week. But we'll pre-schedule a new blog post announcement to send out next Tuesday. See you for the next regularly scheduled Weekly Pulse in two weeks!

There is a narrative starting to gain traction that generative AI is approaching a ceiling. Given the sentiment that GPT-5 is just a small step forward - compared to the splashy iterations that were GPT-3 and GPT-4 - calls abound questioning, "Is it possible that the AI we are currently using is basically as good as it's going to be for a while?"

We think this framing is an overreaction of the consumer mass market. Consumers have gotten used to a jam-packed, pre-trained model delivering magical results in a back-and-forth conversation. And sure, it's likely that we have reached a ceiling on how good that generic chatbox experience can be.

In fact, GPT-5 is apparently optimized for reasoning and intelligence: not knowledge of every nook and cranny of the world. We think this is a smart shift for OpenAI. We now know that adjacent solutions like MCP can retrieve the knowledge on the fly: all that matters for the model is to be able to reason about it all. We don't need to stuff it all inside that pretrained box.

So while consumers may see a stagnated ChatGPT or Claude.ai experience, that's not going to slow down the business world frantically playing catch-up as companies are still wading their way through figuring out how to bring AI, MCP, and all the latest developments of the past 12 months into their businesses. These tools are capable of a lot. 12 months isn't enough for a behemoth company to update its strategy, much less finish implementing new solutions.

In AI-application news, this post questioning Cursor's "Business-Model-Profit-Fit" made the rounds on social media this week. In it, Chris Paik claims that Cursor has an existential blind spot: by subsidizing frontier model costs under a fixed-price cost structure, it's unclear whether their users are just there for the subsidy of the frontier models, or whether they would actually pay an above-COGS rate for the product.

Cursor has two paths out of this: either make a UI/UX layer so good that users will pay the extra fees (this one's obvious), or lower their costs.

This paper from a team of Nvidia researchers paves a compelling path for the cost-cutting approach.

The paper claims that SLMs (Small Language Models) can replace LLMs in many agentic use cases being used today. The idea is that SLMs, which can run on consumer hardware, are actually powerful enough to accomplish the tasks that people are currently using expensive LLMs to do.

Most interestingly, they propose an "LLM-to-SLM conversion framework":

1. Implement your solution with LLMs
2. Log the usage of the solution in production
3. Analyze the logs, clustering the kinds of tasks being completed
4. Select SLM(s) that would do well on those types of tasks
5. Fine-tune those SLMs on your data
6. Replace those LLM invocations with the new SLMs

Not an easy 6 steps. But steps that a powerful and motivated team like Cursor seem plenty capable of pulling off. As could any major company currently bleeding cash to LLM API fees despite massive MRR numbers.

And if companies like Cursor do that, where does that leave the LLM providers, like OpenAI and Anthropic?

We think: they're primed to introduce advertising into their business models. The efficacy of ad-targeting that would be possible inside ChatGPT or Claude.ai would be unprecedented. In the same way that Google Search introduced a new pay-per-ad-click advertising model to capture a huge share of the advertising market - to the tune of $200 billion+ in ARR this year - ChatGPT could quickly command a huge chunk of that, and maybe even grow the market for it further.

OpenAI and Anthropic probably won't bother to make that move until the VC money starts to dry up - which seems unlikely to be the case anytime soon. So we'll continue to enjoy those subsidized tokens while we defer the need to invest in building out those LLM-to-SLM conversions.

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?

→ Core Maintainer Basil has opened a draft SEP that begins to address the ambiguities with "sessions" in MCP that we reported on previously. In brief, it formally defines what is a "session" in the context of MCP, and explicitly unifies those notions of transport and logical sessions. An optional `sessionId` will now be passed around, request-by-request, by servers that want to support statefulness. Because this is significant new functionality, backwards compatibility will have to be achieved by client-server negotiation of protocol version compatibility on initialization.

→ SEP-973, the addition of `icons` and `websiteUrl` into the server initialization handshake, has been approved by core maintainers. By enshrining these two concepts into the core protocol, we'll likely see an uptick in the UX surrounding visual indicators of MCP-related UI elements (like company logos attached to in-progress tool calls) and links to "read more" about servers. In particular, these additions will be handy for the MCP Registry to adopt (here and here).

→ If you're in the market for a crash course on the current state of auth in MCP, there are two official blog posts pushing to land soon from core maintainers Den and Paul. From Den, an end to end guide on properly implementing OAuth in an MCP server. And from Paul, an update on how maintainers are looking ahead to evolving OAuth client registration options. In the MCP Contributor Discord, MCP's auth leaders have recently spun out three distinct working groups: client-registration, improve-devx, and profiles; which gives us a hint as to the likely improvements being prioritized in the pipeline.

→ Anthropic is continuing to invest in DXT, the bundling approach that packages up local MCP servers for easy, standardized execution. They're taking steps to rename DXT, likely to something like MCPB (MCP Bundle) - and have expressed an appetite for potentially proposing that the DXT standard be folded into MCP itself.

→ Maintainer Ola has started working on an official blog post exploring the ins and outs of the Server.instructions field. This little-known but powerful field empowers MCP servers to inform MCP clients how the server is meant to be used as a whole - a step beyond the tool-by-tool descriptions that are most common. When Server.instructions is supported by an MCP client, that can mean getting rid of redundant statements you might otherwise have to include in every tool's descriptions, or explanations of dependencies between tools (e.g. "always call Tool A before Tool B").

→ Along a similar vein, a new proposal is budding with the idea to introduce "requirements" on a tool-by-tool basis. As the MCP specification grows in its feature-richness and potential complexity, many client-server combinations may lag behind in their support of bleeding-edge features. Empowering MCP servers to require certain capabilities from clients before exposing a Tool to them can help bridge that gap.

→ The OAuth client credentials flow SEP, clarifying how machine to machine authorization is meant to work, has been approved by core maintainers. This provides clarity on how to implement MCP spec-compliant auth for cases where there is no end-user to step through an OAuth flow. For example, if you have some process in a CI pipeline that needs to authenticate with and leverage an MCP server.

→ Other work-in-progress we covered last week doesn't have notable updates yet this week: One-click install security, Working Groups & Interest Groups, Default values in Elicitations, Long-running tools (1, 2), WebSockets as an official transport, Enterprise IdP policy controls

Featured MCP Work

shadcn/ui (#45 this week) MCP Server by @Jpisnice
→ This server has been around for about a month, but picked up a spike in popularity this week. While you can get a long way just relying on raw LLMs to facilitate shadcn-driven UI development, this MCP server augments those capabilities with a thoughtfully designed set of tools to pick and choose across shadcn components and other documentation. It's interesting to see a single library/dependency justify an entire MCP server (versus using an all-in-one documentation MCP server like Ref) - but we think it makes sense. More complex libraries (like shadcn) that introduce frameworks and layers of complexity justify such purpose-built tool design. Versus services like Ref can handle the long tail of simpler libraries (but probably do well-enough with the more complex ones for many use cases as well).

Grafana (#55 this week) Official MCP Server
→ Gergely Orosz pointed out this week that Grafana is a quiet but extremely popular tool among mid-sized tech companies: more mentions than even Cursor in his latest survey. As an open source observability platform, Grafana can handle your metrics, logs, and traces: and this MCP server lets you interface with that data. While we at PulseMCP are not on Grafana, we have found that observability MCP servers (Appsignal is ours) are one of MCP's most obvious, valuable use cases: we encourage you to try out whatever MCP server has access to your observability metrics and logs.

Poku Labs (Mon, Aug 18) Official MCP Server
→ Recently released, we think the concept behind this server has massive potential: empower agents (in Poku's case, specifically voice agents) with the ability to "check with a human" before proceeding with a task. The customer service use case in their demo is a great use case, and we think there's a whole lot more to which this pattern (and associated services) can be applied. After all, Elicitations are a first class primitive in the MCP specification. Like we wrote about recently, AI and agents will never replace human trust: so this kind of functionality will be around for a long time to come. Bonus: Poku also offers a creative "tool_approval" MCP server proxy that can gate any remote MCP server behind a human-approval wall.

MCP-Auth: Plug-and-Play MCP Server Auth
→ MCP-Auth makes it easy to add auth capabilities to remote servers - a competitive solution to that of Scalekit we featured a few weeks back. This solution works with IdPs you already trust - like Keycloak, Auth0, Descope - and simply abstracts away the code you would need to implement on top of the base MCP SDKs. Kudos to the MCP-Auth team for its recent contributions in pushing the auth specification forward!

LiveMCPBench MCP benchmark
→ Another benchmark (joining MCPBench, MCP-Radar, MCP-Zero, and MCPEval) for models' abilities to invoke MCP tools is out, and perhaps unsurprisingly, Claude Opus 4 and Sonnet 4 top the list. Notably, the open source model GLM-4.5 came in third (note that GPT-5 was not included; we expect it might have scored in the top 3 as well). Of note: we don't love this benchmark's methodology: they used hundreds of tools and baked in a semantic-similarity search to identify relevant tools to pull into context, which we feel is an ineffective approach to solving tool overload. We'd love to see more benchmarks out there that evaluate models on more realistic scenarios where MCP servers are pre-selected per-evaluation.

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

A Few Good Links

→ Cline explained the philosophy behind its "focus chain" feature, which basically amounts to a thoughtful implementation of the agentic loop's to-do list. We think this "to-do" list feature in an agentic loop is not just a clever trick to get agents to fulfill user requests better - it's absolutely fundamental to a successful agentic loop architecture. Claude Code has an excellent implementation of to-do list management. When an agentic framework does not, you can kind-of roll your own, like we did when digging deep into working with Goose (we called it a "scratchpad" in our writeup) - but we expect native implementations of these "to-do lists" to perform much better for end-users. What's interesting is that the right to-do list management architecture for developers writing code might look a little different than other personas wielding AI - a creative marketing copywriter's workflow in a Google Doc looks quite a lot different than the software engineer who spends most of their day spelunking through hundreds of code files - and so we expect that nailing this "agentic to-do list management" is a key ingredient in building a successful MCP client / agentic app for some persona you wish to serve.

→ Clever uses of the Claude Code SDK keep rolling in. Our favorite we spotted this week, while not yet released, is @JacobColling working to replace his Google Home with Claude Code. It's no secret that all the voice assistants of the past several years have very much failed to deliver on their promise of seamless voice-interactive experiences that connect you to the digital world. And all the ingredients are now there: great voice-enabled LLMs, MCP servers that hook into whatever service you want, and all glued together with a highly capable Claude Code SDK-powered agentic loop.

→ Google Flights is launching an AI-powered experience for finding flight deals. On the surface, the announcement feels like an exciting AI-powered product launch - who wouldn't want to skip that tedious poking around playing with dozens of possible flight options to find the one that suits your itinerary just right? And who better to provide a great experience than the leading flights aggregator backed by a frontier AI team? Alas, we think this product release very much misses the mark. It's highly constrained to "deals," and has a very limited one-shot interface. There is a great opportunity here for Google to build an excellent flight search product - and if they don't want to do it themselves, they could easily release a Google Flights MCP server that embeds their monetized booking links. Instead, this product is months behind the latest thinking on AI-powered UX, and they're getting upstaged by smaller players like Kiwi.com, who have released a well-designed alternative MCP server that should outperform whatever Google is trying to do here.

→ OpenAI is reportedly facilitating a round of secondary share sales that value the company at $500 billion, nearly doubling its March valuation of $300 billion. While it's hard to imagine the current pay-for-API-access business model scaling up to properly support a valuation of that size, it feels less outlandish if you look at it from the lens of the hundreds of billions of annual advertising revenue we mentioned above that might be within reach.

→ Perplexity picked up some publicity for its unsolicited offer to buy Chrome for $34.5b - nearly twice its own $18b valuation, but allegedly supported by other financial backers. It's not entirely out of the blue: the DOJ has ruled that Google must sell Chrome, and an offer like this probably supports the case against Google's appeal. Nonetheless, the community criticized Perplexity, suggesting this was just a publicity stunt worthy of a new series of memes. The move certainly doesn't inspire confidence in the future of Comet, Perplexity's browser - we don't think Chrome is going to be dethroned as the browser of choice any time soon.

→ In a surprising twist in that Cloudflare vs. Vercel back and forth regarding whether AI crawling bots should be blocked, Vercel's CEO penned an unprompted post that repeated the exact point we made last week: there are different kinds of AI crawlers; and depending on your type of business, some should be blocked, and others should be set free. Finally, something Cloudflare and Vercel can agree on - and the rest is just implementation details.

→ Claude Sonnet 4 now supports a 1 million token context window, up from 200k previously. This matches the much-lauded context window of Gemini 2.5. As those Claude Code agentic workflows get better and longer, this upgrade is a helpful reprieve that could improve performance in those situations; but note that it does come at premium pricing once you exceed 200k.

→ Armin Ronacher, creator of Flask, wrote up a blog post detailing why he thinks many MCP servers don't need dozens of tools; he says they need just one, the ability to invoke code. On using CLI tools instead of MCP, he exposes the limitations, like "when your tool is absolutely not in the training set and uses unknown syntax. In that case, getting agents to use it can become quite a frustrating experience." He uses Playwright as an example, where he distills down the typical 30+ tools to a single `playwright_eval` tool, and it appears to work quite well. Our opinion: while we think he takes it a step too far to suggest that all MCP servers would do well to expose a single, code-invoking tool, we do think the concept of "a single tool" has significant merit. We designed something similar in our Pulse Fetch implementation: we offer a single tool, `scrape`, with a set of thoughtful parameters rather than a kitchen of scraping-related tools like many alternative scraping-related MCP servers offer. A look at one of our features this week, Poku Labs, indicates a similar pattern: the whole product is built around a single `contact_human` tool. The insight that raw code is the right abstraction layer is probably only relevant to CLI-tool-alternative developer use cases, but the idea that you probably need fewer tools than you think can generalize quite well.

→ We've long been holding the hypothesis that officially-maintained MCP servers to first party APIs are going to outperform community-built alternatives. But we're starting to think this uptake might take longer - perhaps years, in the case of some services - than we thought. @iceener penned a thoughtful breakdown as to why his unofficial Linear implementation outperforms the official implementation. Similarly, we had a great experience using this unofficial Railway MCP server at one point, and the recent official release has come off as disappointing: it requires the official CLI installed, it lacks comprehensive functionality, and relies on pre-made templates. The lag in official uptake might have a long road ahead, and so community builders have a temporary arbitrage opportunity to build great servers, amass a userbase and following, and either monetize that directly or use it as lead generation for some adjacent offering.

Cheers,
Mike and Tadas