10 posts tagged with "Deep Dives"

Every Model Context Protocol server on the internet is, at the end of the day, a URL. The hard question is which AI tool you're going to plug it into — and the honest answer is that the experience varies wildly depending on which app you live in.

I run MCPBundles, so I see what users actually do after they generate an MCP URL. A lot of them sign up, get the URL, then bounce because the next step — wiring it into the tool they actually use — is unfamiliar territory. Sometimes that's our fault for not making it obvious. Sometimes the tool's setup flow is genuinely awkward. And sometimes the tool literally hides MCP behind a developer toggle that nobody told you to flip.

This is the field report I'd write a friend who asked me, today, "which AI tool should I use if I want MCP to actually work?" Frank, opinionated, with the quirks named.

Stanford's Digital Economy Lab just published The Enterprise AI Playbook — a 116-page study of 51 successful enterprise AI deployments across 41 organizations, 9 industries, and 7 countries. The research team, led by Erik Brynjolfsson (one of the most-cited economists on technology), interviewed executives and project leads who deployed AI at scale and measured actual results.

The headline finding: the technology was never the hard part. In 77% of cases, the hardest challenges were invisible — change management, data quality, and process redesign. Not model selection. Not prompt engineering. Not which AI provider to use.

This post pulls out the findings that matter most for anyone building or buying AI tooling today.

MCP Apps look simple in the spec. Your tool returns HTML, the host renders it in an iframe, the user sees a dashboard instead of a wall of JSON. Build one app, it works everywhere.

In practice, I've shipped MCP Apps to both ChatGPT and Claude over the past few months and learned that "works everywhere" requires handling a surprising number of sharp edges — iframe sandboxing, data format differences, a picky initialization handshake, and an interactive tool-calling pattern that's barely documented anywhere.

Here's everything I've learned, with the exact code for each one.

There's a war happening on Reddit right now, and it's getting heated.

On one side: developers who believe the Model Context Protocol is overengineered middleware — that AI agents should just call gh issue create and curl like any terminal user. On the other: engineers running MCP in production who say the skeptics will inevitably reinvent every feature MCP provides, just worse.

Both sides are partially right. But the debate itself is framed wrong.

I spent the last day using our MCPBundles CLI to search Reddit via MCP tools — browsing posts, pulling comment threads, analyzing arguments — all through authenticated MCP tool calls executed from the command line. The irony was not lost on me: I was using CLI to call MCP to read arguments about whether we need MCP or CLI.

The answer, as it turns out, is both. But not in the way most people think.

We ran into a problem a few weeks ago that none of our tools could solve. It wasn't a technical problem — the code was fine, the infra was fine. We just needed someone to go do a thing on a website. Sign up, click around, grab some information, paste it into a form. Repeat a bunch of times.

AI couldn't do it. The sites had captchas, email verification, multi-step flows. We tried browser automation and it broke immediately. We needed a person.

So we thought: what if our AI agent could just hire one?

MCP Apps (SEP-1865) is a recent extension to the Model Context Protocol that lets a server hand the host an interactive UI rather than only text or structured JSON. The host renders that UI inside its own surface — Claude Desktop, ChatGPT and Cursor have all been moving in this direction — and the UI can call back into the server through the existing MCP transport.

The reason it matters is that a lot of the things people want agents to do are not really text-shaped. A pipeline view, a comparison chart, a form with validation, a sortable table — these have always been awkward to express as a tool response. MCP Apps gives them a first-class home without throwing out the auth, sandboxing or audit story that MCP already had.

Users would ask Claude to "set up all my integrations," and Claude would call our provisioning tool. Then nothing. Users waited 45 seconds staring at a spinner while our server created API keys, configured webhooks, and set up OAuth clients. Most users gave up after 15 seconds, thinking it failed.

Then someone asked Claude to "clean up old bundles," and Claude dutifully deleted everything from the last 6 months. Because we let it.

We needed streaming for long-running work, chunking for large operations, and approval gates for anything scary. Here's what works.

Our bundle search tool was taking 12 seconds at P95. Users would ask Claude to "find the Slack integration," watch nothing happen, then ask again. Claude would make the same call twice, wait 24 seconds total, and users would close the tab thinking our service was down.

The tool worked perfectly. It just worked slowly. And in the world of AI assistants, slow might as well be broken.

Here's the thing about schemas: they're basically the contract your model learns from. Get them right, and your tools are easy to find, hard to break, and simple to fix when something goes wrong.

Get them wrong, and you'll spend way too much time debugging why the model keeps calling your tool incorrectly.

For the first month or two of building agents on Claude, I spent most of my debugging time staring at hallucinated API endpoints. The model would confidently POST to URLs that didn't exist, invent function names, and produce JSON that wouldn't parse. Switching the integration over to the Model Context Protocol (MCP) didn't fix everything, but it removed the entire class of "the model made up an endpoint" failures, which were the bulk of what we were chasing.

The rest of this post is the explanation I wish I'd had on day one.