Since then, a common question I've received is: "Why bother building an MCP (Model Context Protocol) interface? Why not just use a standard REST API and let the agent call it?"

It's a fair question. As AI agents (like Cursor, Claude Desktop, and custom autonomous agents) become the primary consumers of our software, the way we design interfaces is fundamentally shifting.

Here is our journey of migrating a traditional API to an MCP server, why we did it, and the technical hurdles we faced along the way.

Why Migrate to MCP? (The Agentic Advantage) Standard REST APIs are built for deterministic clients (like a web frontend or a mobile app). The client knows exactly what to send and how to handle the response. LLMs, however, are probabilistic. If you give an LLM an OpenAPI spec and tell it to use it, it often gets confused. It might hallucinate parameters, or you have to write massive system prompts just to explain how to use your API.

MCP changes this by being "AI-native":

Dynamic Tool Discovery: MCP servers declare their capabilities directly to the agent. The agent doesn't need to guess; it just asks the server, "What can you do?" and receives a structured list of tools and their schemas.

Context Efficiency: Instead of a massive OpenAPI JSON file eating up tokens, MCP provides concise, LLM-readable tool descriptions.

Built-in Streaming: MCP uses Server-Sent Events (SSE) natively, which is perfect for agents to receive real-time updates on long-running tasks.

Is Your Use Case Suitable for MCP? (The Audio/Video Test) If you are processing text or simple database queries, a standard API wrapper might be enough. But if your system deals with heavy audio/video processing, MCP is a lifesaver. Here is why audio/video is the perfect candidate for MCP:

Asynchronous Nature: Audio transcription or video rendering takes time. You don't want the agent's reasoning loop to block for 3 minutes.

Context Window Limits: You can't pass a 50MB .mp4 file or a base64 string directly into a prompt.

Separation of Concerns: An MCP server acts as a "broker." It receives the intent from the agent, uploads the file via a presigned URL, kicks off the backend processing, and returns a task_id to the agent. This keeps the LLM's context window clean and focused.

Technical Hurdles During Migration (What We Learned) Wrapping a REST API in an MCP SDK is the easy part. The hard part is adapting the logic for a non-deterministic AI. Here are the biggest challenges we faced: A. Redesigning Schemas for LLMs A standard REST API might return a massive JSON object with 50 fields. An LLM doesn't need all that. We had to redesign our tool schemas to be incredibly descriptive and concise. The tool description needs to tell the LLM when and why to use it, not just what it does.

B. Error Handling for AI If your REST API throws a 500 Internal Server Error, a human developer checks the logs. If an MCP tool throws that same error, the AI gets stuck. The fix: Return errors as natural language that the AI can read and self-correct from. For example: "Error: File exceeds 25MB. Please ask the user to compress the file or use the upload_large_file tool instead." This allows the agent to autonomously fix its own mistake.

C. Handling Large Payloads As mentioned in my previous post, you cannot pass raw files. We had to enforce a strict rule: The MCP server only returns text or URIs. The AI gets a presigned URL to read or upload from, completely bypassing the context window.

Keeping the System Stable Post-Migration Once the agent is connected, you'll quickly realize that AI agents can be "impatient" and aggressive. Here is how we stabilized our MCP server: Idempotency Keys: Agents will retry tool calls if they don't get a response fast enough. We implemented idempotency keys so repeated calls don't process the same video twice.

Strict Timeouts & "Fail Fast": Don't let an agent poll a check_task_status endpoint indefinitely. We built a hard timeout on our side. If a task takes longer than X minutes, the tool returns a clear failure, preventing the agent from entering an infinite loop.

Rate Limiting by Agent ID: If you are serving multiple agents or users, ensure you rate-limit at the MCP level, not just the backend level, to prevent a runaway agent from DDoS-ing your own infrastructure.

Conclusion Migrating from REST to MCP is not just a technical refactor; it's a mindset shift from building for deterministic humans to building for probabilistic agents. It requires you to rethink how your data is passed, how errors are communicated, and how tasks are sequenced.

But the payoff is huge. Once your API is MCP-compatible, it instantly becomes a powerful tool for the entire ecosystem of AI agents.

Have you started building MCP servers? What challenges have you run into? Let me know in the comments below!

If you want to dive straight into the code, the full implementation of this MCP server architecture is open-sourced on GitHub https://github.com/warmcoding . Feel free to star it or open an issue if you have any questions!