DEV Community: Shreyaan Seth

We Invented MCP Just to Rediscover the Command Line

Shreyaan Seth — Sun, 29 Mar 2026 08:53:26 +0000

Time moves differently in the AI era. Right now, one year packs roughly half a decade of standard tech cycles.

We used to watch software patterns run their full lifecycle in slow motion. Think about jQuery, Angular, or the Next.js Pages Router. Each of them took about five years to complete the arc: peak hype, messy real-world adoption, the slow-motion collision with technical debt, and finally, the quiet retreat back to what actually works.

MCP (Model Context Protocol) just did that entire speedrun in under twelve months.

When Anthropic launched it in late 2024, the LinkedIn crowd immediately crowned it the "USB-C for AI." By mid-2025, every major IDE had integrated it, the ecosystem hit nearly 100 million monthly SDK downloads, and developers were shipping demo servers in an afternoon, happily declaring the agent-integration problem solved.

Then everyone actually tried to run it in production.

Once the hype cleared, three massive cracks appeared in the foundation.

The token math is brutal

Every tool you expose to an LLM eats tokens. Not a little. A lot.

Cloudflare recently did the math on this. To expose their API's 2,500 endpoints via a standard MCP server, the schema definitions alone would consume 1.17 million tokens. That’s more than the entire context window of today's frontier models, completely nuked before the user even types a prompt.

You don't even need to be Cloudflare to hit the wall. Apideck documented a real-world deployment where just three MCP servers (GitHub, Slack, and Sentry) loaded roughly 40 tools. That consumed 143,000 tokens out of a 200,000-token window. That is 72% of the model's working memory, gone.

The irony here is structural. The more capable you want your agent to be—the more tools you give it—the dumber it gets, because the tool schemas literally crowd out the model's ability to reason.

Auth doesn't survive the enterprise

MCP's specification openly leaves consent and authorization flows up to the implementor. In practice, this means every dev team is currently reinventing auth from scratch, usually poorly, and usually under a deadline.

The production reality is grim. Enterprises building on REST APIs solved rate limiting, tamper-proof audit logs, and role-based access control a decade ago. MCP threw those lessons out the window to make tool-calling feel elegant in local demos.

As a result, MCP holds zero certifications for SOC 2, PCI DSS, or FedRAMP. The OAuth specification conflicts with modern enterprise practices. At the RSA Conference recently, researchers demonstrated how an MCP vulnerability could enable remote code execution and a full takeover of an Azure tenant. It's an auditor's worst nightmare.

Tool calling is the wrong primitive entirely

This is the deepest crack, and the one that took the industry the longest to admit.

LLMs have an enormous amount of real-world TypeScript and Python in their training data. They have almost no training data on blindly navigating a bespoke menu of native MCP tools. The implication is obvious in hindsight: LLMs are fundamentally better at writing code than they are at clicking buttons.

Cloudflare proved this empirically. They compared an agent using direct tool-calling to an agent using "Code Mode" to create 31 calendar events. The tool-calling agent fired off 30+ individual, sequential calls, forcing the model to re-process the context every single time. The Code Mode agent just wrote a simple loop and iterated over the dates in a single execution.

By converting their 2,500 endpoints from a traditional MCP approach down to a typed SDK that the model just writes code against, Cloudflare dropped token usage by 81%.

The tool-calling paradigm treats LLMs as dumb orchestrators. Code generation treats them as what they actually are: very good programmers.

The 12-Month Reversal

Over the last few weeks, the public reckoning finally arrived.

At the Ask 2026 conference a couple of weeks ago, Perplexity CTO Denis Yarats announced the company is abandoning MCP internally in favor of traditional APIs and CLIs. They cited context window consumption and clunky auth. The kicker? Perplexity had just shipped their own MCP server four months prior. They built it, ran it in production, hated it, and reversed course inside a single quarter.

Y Combinator president Garry Tan put it bluntly on X: "MCP sucks honestly... I got sick of it and vibe coded a CLI wrapper instead," citing reliability and speed. Over on Hacker News, a tool called mcp2cli—which literally converts MCP tools back into plain CLI commands—hit the front page, boasting a 99% token reduction.

Meanwhile, Cloudflare officially shipped Code Mode as their direct answer. Instead of exposing thousands of tools, the model writes code against a typed API. Two tools. Under 1,000 tokens. The entire Cloudflare API, instantly accessible.

The pendulum snaps back

If you've been in web development long enough, you know the joke: we went from server-rendered pages, to complex client-rendered SPAs, right back to server-rendering. A clean, decade-long circle that cost the industry millions of hours.

We just watched AI tooling do the exact same loop in one year.

We scrambled from basic APIs, to a highly sophisticated tool-calling protocol, only to slam into its limitations and land right back on 30-year-old ideas: the command line, the REST endpoint, the typed SDK. Julien Simon flagged these exact problems publicly in mid-2025—session models failing to scale horizontally, auth as an afterthought, JSON overhead—and was rewarded with angry messages for being a hater. Eight months later, Perplexity's CTO stood on stage and said the exact same things.

This is what building in the post-AI era actually looks like. The pendulum still swings, it just swings violently fast. Hype cycles that once took five years now complete in a single product cycle. The lessons are the same, the tuition just gets collected faster.

If you're building agents right now, the question isn't how to wedge the newest protocol into your stack. The question is: what is the absolute simplest primitive that actually solves my problem?

Nine times out of ten, somebody already invented it decades ago.

A typed SDK. A REST endpoint. An API key. A CLI. The frameworks we build on top of them are valuable, but when the framework starts fighting the foundation, the foundation always wins.

The teams that figure this out fastest, who resist the siren call of the elegant new abstraction until it's actually earned its place, are the ones who will ship agents that actually work in production. Everyone else will spend the next twelve months debugging context overflow errors and OAuth flows while the cycle repeats itself, faster than ever.

Why BookMyShow "Failed" but Hotstar Succeeded - A System Design Perspective

Shreyaan Seth — Sun, 22 Sep 2024 09:07:42 +0000

I've seen a lot of people asking why BookMyShow struggled during events like the Coldplay concert, while platforms like Hotstar seem to manage massive traffic, especially during big cricket matches. To answer that, we need to understand this from a system design and infrastructure perspective—and it's not exactly a fair comparison.

Apples to Oranges: Read-heavy vs Write-heavy Systems

Hotstar and BookMyShow are fundamentally different in how they handle user interaction. Hotstar is read-heavy, where millions of users are simply streaming content (reading data). On the other hand, BookMyShow is write-heavy during high-demand events like concert ticket sales, with a surge of users writing data—attempting to buy tickets at the same time.

Consistency, Data Loss & Expectations

Another key difference is the expectation of consistency and data loss:

Hotstar: When a user streams a video, slight inconsistencies or minor data loss aren't catastrophic. The platform can handle the load by buffering, lowering stream quality temporarily, etc.
BookMyShow: For ticket sales (especially payments), there's zero tolerance for inconsistency or data loss. Losing transaction data or overbooking tickets can lead to serious financial issues and customer dissatisfaction.

During the Coldplay concert, BookMyShow faced extreme demand for limited inventory (tickets), leading to write-heavy traffic that stressed their system. In contrast, Hotstar scales to handle a massive number of read requests during cricket matches, where the infrastructure is optimized for real-time video delivery.

Both are successful platforms, but their system designs are built for very different kinds of traffic and failure modes. It's a great case to study if you're diving into system design—understanding the trade-offs of read-heavy vs write-heavy platforms is key.

The Unsung Hero: Uses of the HEAD Request in APIs

Shreyaan Seth — Sun, 31 Mar 2024 14:35:40 +0000

When working with APIs, we're all familiar with the standard HTTP methods like GET, POST, PUT, and DELETE. However, there's another method that often gets overlooked: HEAD. Despite its simplicity, the HEAD request can be a powerful tool in your API arsenal, offering several useful applications. Let's dive in and explore the world of HEAD requests.

What is a HEAD Request?

A HEAD request is similar to a GET request, with one key difference: instead of retrieving the full response body, it only retrieves the response headers. This means that a HEAD request won't actually fetch the resource itself, but it will provide you with metadata about the resource, such as content type, content length, cache control, and other relevant headers.

The body of an HTTP message refers to the actual data or content being transferred. In the case of a GET request, the body contains the resource being retrieved, such as an HTML file, an image, or any other type of data. For a POST request, the body typically carries the data being sent to the server, like form data or a JSON payload.

On the other hand, the headers are metadata included in both the request and response messages. They provide additional information about the request or response itself, rather than the actual content being transferred. Headers are key-value pairs that convey important details, such as:

Request Headers:

Host: The domain name of the server
User-Agent: Information about the client (browser, operating system, etc.)
Accept: The types of content the client can handle (e.g., text/html, application/json)
Content-Type: The type of data being sent in the request body
Authorization: Credentials for authentication

Response Headers:

Content-Type: The type of data in the response body
Content-Length: The size of the response body
Cache-Control: Caching instructions for the client and intermediaries
Last-Modified: The last time the resource was modified
ETag: A unique identifier for the resource version
Server: Information about the server software

Use Cases for HEAD Requests

Resource Existence and Accessibility Checks

One of the primary use cases for HEAD requests is to check if a resource exists and is accessible without actually retrieving the resource itself. This can be particularly useful when dealing with large files or resources that you don't necessarily need the full content for, saving bandwidth and server resources.

Content Negotiation

HEAD requests can be leveraged for content negotiation, which is the process of determining the best representation of a resource based on the client's preferences and capabilities. By examining the response headers from a HEAD request, you can determine the available representations (e.g., different content types, encodings, or languages) and select the most appropriate one for your needs.

Conditional Requests

HEAD requests can be used in conjunction with conditional headers like If-Modified-Since or If-None-Match to perform conditional requests. This allows you to efficiently check if a resource has been modified since the last time you retrieved it, avoiding unnecessary data transfers and reducing server load.

Retrieving Metadata

In some cases, you might only need specific metadata about a resource, such as its content length, content type, or other header information. A HEAD request can provide this metadata without the overhead of retrieving the entire resource, making it a more efficient option than a full GET request.

API Monitoring and Health Checks

HEAD requests can be employed for API monitoring and health checks. By periodically sending HEAD requests to specific API endpoints, you can verify that the endpoints are up and running without putting unnecessary load on the server or consuming excessive resources.

Example Usage

Here's an example of how you might use a HEAD request with JavaScript's fetch API:

fetch('https://api.example.com/resource', {
  method: 'HEAD'
})
  .then(response => {
    console.log('Response Headers:', response.headers);
    // Additional logic based on the response headers
  })
  .catch(error => {
    console.error('Error:', error);
  });

In this example, we're sending a HEAD request to the specified URL using the fetch API. The response object contains the response headers, which we can inspect and use for various purposes, such as checking the content type, content length, or any other relevant headers.

Real-World Usage Examples

Content Negotiation in Next.js

In Next.js, you can render components at the server and send the final HTML without huge JavaScript bundles. This means that if you want to use different libraries for different types of content, you can check quickly what the type of file is and send only the required libraries, providing the best user experience and saving resources.

File Existence in S3

You can also use the HEAD request to check if files are present in an S3 bucket. If all files are added, you can determine what's missing.

Reverse Proxy Caching

Reverse proxies use HEAD requests to validate if a cached resource is still fresh, serving the cached version if so to reduce origin server load.

API Rate Limiting

Check rate limiting headers with HEAD requests before making resource requests to avoid getting rate limited unexpectedly.

Web Crawlers

Crawlers send HEAD requests with If-Modified-Since to check if a resource has changed since last crawled, avoiding refetching unchanged content.

Conclusion

While the HEAD request might not be as commonly used as other HTTP methods, it can be a valuable tool in your API development arsenal. By leveraging HEAD requests, you can perform resource existence checks, content negotiation, conditional requests, retrieve metadata efficiently, and monitor API health. So, the next time you're working with APIs, don't overlook the power of the humble HEAD request!

Unlocking Smooth Downloads: A Guide to User-Friendly File Download After User Actions (POST Requests)

Shreyaan Seth — Mon, 25 Mar 2024 13:34:12 +0000

What Happens When You Click "Download"

First, let's understand what occurs when you click a "Get File" or "Download File" button on a browser. It turns out it's simply a basic GET API call. We call the URL using the href attribute on an <a> tag, and it returns a file, which we can consider a blob. By adding the download attribute to the <a> tag, we can simply download that blob.

<a href="path/to/your/file.pdf" download="myfile.pdf">Download File</a>

The browser then intercepts the download and shows progress, speed, and the estimated time remaining (ETA), creating a great user experience (UX). The user is updated and doesn't get confused at any point.

Here's an example:

The Issue with Uploading Data

Now, sometimes we need to send some data to the server to manipulate a file, usually to create a new one. Here's where things get tricky. To do this, you need to make a POST request. The server receives the request, performs the necessary tasks, and then sends the file. So far, so good.

The Problem with Downloading After POST

To download the file after a POST request, we typically do something like this:

const response = await fetch(
  url,
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ name: "John Doe" }),
  }
);
const blob = await response.blob();
const url = URL.createObjectURL(blob);
const link = document.createElement("a");
link.href = url;
link.download = "file.zip";
link.target = "_blank";
document.body.appendChild(link);
link.click();
document.body.removeChild(link);

There's a problem with this approach, though. The browser's download manager doesn't intercept the download. Users have no idea when the file is ready, when the download started, what the speed is, or the estimated time remaining (ETA). This might be okay for tiny files, but it's a terrible experience for files larger than even 5 MB.

Here's an example of this issue:

The Fix: Storing and Downloading Later

So, how can we generate files on demand but still allow the browser to handle the download, displaying progress, ETA, and maybe even enabling parallel downloading?

The fix is simple: you have to store the file somewhere and send the link to the user. Then, just open it in a new tab.

const response = await fetch(
  "url",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ name: "John Doe" }),
  }
);
const url = await response.text();

window.open(url, "_blank");

This way, the file is handled by the wonderful browser!

Here's an example of this solution:

Try it Yourself!

The examples I used are hosted here: https://post-request-blog.vercel.app/ You can try them out and fully understand what I mean. Feel free to snoop around in the network tab for the POST requests to get a better grasp of the process.

Code Repository

Here's the GitHub repository for the code: https://github.com/Shreyaan/post-request-blog

Simplifications

For simplicity, I took some shortcuts, such as not using a proper backend with Node.js or Python and instead using Next.js. In a real-world scenario, a public folder on the backend would be used to store the file. Additionally, I'm using the first API's URL as the URL returned by the third API. Ideally, the third API would return the URL of the generated and stored file in the public folder.

I hope you enjoyed this and learned something new!

Caching Behavior of get Requests in Next.js 13+

Shreyaan Seth — Tue, 19 Mar 2024 16:21:13 +0000

This blog post summarizes some key points about caching behavior for GET requests in Next.js versions 13 and above, referencing the official Next.js documentation for details.

Default Caching:

By default, Next.js automatically caches the results of most GET requests made using the fetch API. This improves performance by serving cached data on subsequent requests, reducing the need to fetch data from the server again.

Opting Out of Caching:

There are situations where you might want to prevent Next.js from caching a GET request. One such scenario involves fetching data that depends on user-specific information like cookies. For example, imagine a function that retrieves a user's authentication token from cookies. Since the token is unique to each user, you wouldn't want Next.js to cache the response, as it wouldn't be valid for other users.

The Next.js documentation (Data Fetching, Caching, and Revalidating ) explains how requests that involve headers like Authorization or Cookie are automatically excluded from caching. This ensures that authenticated users always receive fresh data specific to their accounts, preventing unauthorized access to other users' information.

In many other cases where cookies are involved, Next.js might also opt-out of caching by default. It's recommended to refer to the official documentation for a comprehensive list of scenarios that trigger this behavior.

Manual Opt-In for Caching:

If you do want to cache a GET request that involves cookies or other headers that would normally disable caching, you can explicitly instruct Next.js to cache it. This is done by adding the next: { tags: [...] } option to the fetch call.

fetch(url, { next: { tags: [...] } });
The tags property allows you to define a list of identifiers for the cached data. You can then use the revalidateTag function (https://nextjs.org/docs/app/api-reference/functions/revalidateTag ) to invalidate the cache for specific tags, triggering a refresh of the data.

Benefits of Manual Caching:

Even though user-specific data shouldn't be cached, there could be other GET requests within your application that benefit from caching. By manually opting-in for caching with tags, you can improve the performance of your application by serving cached data for those specific requests. Additionally, using revalidateTag allows you to selectively update cached data when necessary, providing a balance between performance and data freshness.

In Summary:

Next.js automatically caches most GET requests by default.

Requests involving cookies or other specific headers are typically excluded from caching to ensure data security.

You can manually opt-in for caching with tags and use revalidateTag for selective cache updates.

Remember to refer to the official Next.js documentation (https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating ) for a more detailed explanation of caching behavior and configuration options.

Why Do You Need a JavaScript Framework anyways?? How React, Vue, Can Save You Time and Effort

Shreyaan Seth — Tue, 13 Dec 2022 17:24:49 +0000

As a web developer, I know firsthand how challenging it can be to build a dynamic website using plain JavaScript. Without the right tools and techniques, it can be a struggle to keep your code organized, maintainable, and scalable. That’s why I’m a big fan of JavaScript frameworks like React, Vue, Angular and others — they provide a solid foundation and a standardized structure for your code, making it easier to build complex, dynamic web applications.

As a web developer, you might be wondering, “Why do I need a JavaScript framework at all? Can’t I just write all of my code from scratch using plain JavaScript?” While it’s certainly possible to build a web application without a framework, doing so can be quite difficult and time-consuming.

Consider, for example, a real-time chat application that needs to update the conversation in real time as new messages are sent and received. With plain JavaScript, you would need to write a lot of code to handle the websocket connections, track the state of the conversation, and update the page in real-time as new messages arrive. This can quickly become overwhelming, as you have to worry about managing all of the different components and interactions yourself.

You would need to write code to create and manage the WebSocket connections, as well as code to track the state of the conversation and update the page in real-time as new messages arrive. You would also need to write code to handle user interactions, such as sending and receiving messages, and code to handle any errors or edge cases that might arise. All of this code would need to be carefully organized and maintained to ensure that your application works correctly and efficiently.

In contrast, a JavaScript framework like React would provide a standardized structure for building this chat application. React would handle the WebSocket connections, state management, and real-time updates for you, allowing you to focus on the core functionality of your application. With React, you could write a chat application with just a few lines of code, using the framework’s standardized structure and built-in optimization techniques to create a performant, efficient application.

lets take another example: a simple to-do list app. With plain/ vanilla JavaScript, you would need to write a lot of code to create the app, including code to handle user interactions, track the state of the to-do list, and update the page in real-time as items are added and removed. Here’s a sample of what that code might look like:

const toDoList = [];
function addToDo(item) {
  toDoList.push(item);
  updatePage();
}
function removeToDo(index) {
  toDoList.splice(index, 1);
  updatePage();
}
function updatePage() {
  // code to update the page with the current to-do list
}

As you can see, this code is relatively simple, but it would quickly become overwhelming as you add more features and functionality to your app. You would need to write code to handle user interactions, such as adding and removing items from the list, as well as code to update the page in real-time. This can quickly become difficult to manage, especially as your app grows and evolves.

But with a JavaScript framework like React, you can easily build this same to-do list app with just a few lines of code. React provides a standardized structure for your code, allowing you to break your application into small, reusable components that can be easily composed and updated as the state of your application changes. Here’s a sample of what that code might look like using React:

here’s a sample of what the to-do list app might look like using React:

import React, { useState } from 'react';
function ToDoList() {
  const [toDoList, setToDoList] = useState([]);

function addToDo(item) {
    setToDoList([...toDoList, item]);
  }
  function removeToDo(index) {
    setToDoList(toDoList.filter((_, i) => i !== index));
  }
  return (
    <div>
      {toDoList.map((item, index) => (
        <div key={item}>
          {item}
          <button onClick={() => removeToDo(index)}>Remove</button>
        </div>
      ))}
      <input
        type="text"
        placeholder="Add a to-do"
        onKeyDown={event => {
          if (event.key === 'Enter') {
            addToDo(event.target.value);
            event.target.value = '';
          }
        }}
      />
    </div>
  );
}

As you can see, using React allows you to build this to-do list app with just a few lines of code.

(the code may look bigger but its almost an complete app!!! unlike plain javascript which will do nothing)

Additionally React’s component-based approach would make it easy to break your application into small, reusable components that can be easily composed and updated as the state of your application changes. This can make your code more modular and easier to understand, which can save you time and effort in the long run.

In short, JavaScript frameworks like React, Vue, Angular and others can provide numerous benefits for web developers. They can save you time and effort, help you write better code, and make your application more performant and efficient. Whether you’re building a simple web page or a complex web application, a JavaScript framework can be a valuable tool in your toolkit.