Most APIs weren't built for AI agents. Stripe has 300+ endpoints. GitHub's API returns paginated results that change between requests. Slack rate-limits you after 20 calls per minute. None of them were designed for Claude to use directly.

We wrapped dozens of REST APIs into MCP tools and learned that a thin wrapper doesn't work. You need to rethink the interface completely—actions instead of CRUD, consolidated search instead of endless list endpoints, and server-side resilience for pagination and rate limits.

Here's what actually works.

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.

MCPs work like magic. Internally we use them relentlessly inside Cursor, for Linear issues in particular. We decided to ship an MCP server with MCP Bundles mainly because it made sense for us to have it on our own product for testing, before we even provided it to our customers. We built it quickly and made choices-of-least-resistance so there may be better ways to do everything. This is why we wanted to share our experience, would love to hear your feedback.

So the headline is we decided to implement an MCP server, Model Context Protocol (MCP), in our Django application, built on top of our existing API endpoints, and get it working with Cursor and Claude 3.7.

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.

I spent two hours staring at Claude Desktop wondering why my MCP server wouldn't connect. The config looked perfect. The server ran fine standalone. But Claude showed no tools. The problem? A single trailing comma in my JSON config that Claude silently ignored.

This is everything I wish the docs had told me upfront.

New to MCP? Start with Introduction to MCP to understand what it is and how it works.

My first MCP server took three hours to get working because I made every possible mistake: no logging, broke stdio with print statements, forgot to restart Claude Desktop, and wondered why nothing worked. Your first one should take 30 minutes.

This is what actually works, with the debugging steps I wish I'd known upfront.

I watched Claude hallucinate API endpoints that didn't exist, confidently call made-up functions, and crash our systems with broken JSON. Then we implemented the Model Context Protocol (MCP), and our error rate dropped from 28% to under 3%.

This is what I wish someone had told me when I started.