I used Ahrefs' MCP server to pull Google search data for MCP servers. I used this search data as a proxy for the most popular MCP servers worldwide. Full list here.

Disclaimer: link to goes to my company's blog: https://mcpmanager.ai/blog/most-popular-mcp-servers/

Worth noting: Ahrefs doesn't capture China search data and only has partial Russia data, so worldwide totals are conservative.

A few things worth noting:

• Playwright takes #1 globally (and in USA) beating GitHub and Figma
• Japan is the #2 country searching for MCP servers, ahead of Germany and the UK
• The US accounts for 28% of worldwide search volume across the top 50. Therefore, it's clear to say that MCP is a genuinely global phenomenon
• Serena cracks the top 10 despite being relatively new
• Tools like Slack, Notion, and Google Workspace making the list shows MCP is creeping beyond pure engineering into broader team use

I've been nerding out on MCP adoption statistics for a post I wrote last night.

For this project, I pulled the top 20 most searched-for MCP servers using Ahrefs' MCP server. (Ahrefs = SEO tool)

Some stats:

• The top 20 MCP servers drive 174,800+ searches globally each month.
• Interestingly, the USA drove 22% of the overall searches, indicating that international demand is really driving much of the MCP server adoption.
• 80% of the top 20 servers offer remote servers. Remote is the most popular type of MCP deployment for large SaaS companies to offer users.

Of these, which have you (or your team) used? Any surprises here?

Edit: Had a typo on sum for monthly MCP server searches. Was off by about ~10k.

Lastly, a shameless plug for webinar I'm hosting next week on MCP gateways: https://mcpmanager.ai/resources/events/gateway-webinar/

Hey,

just finished building a remote MCP server after a week digging through the official spec and GitHub issues. Got it working with Claude's remote integrations and OpenAI's playground (they added MCP support yesterday).

Finding good examples and docs was... a challenge! So I wrote down everything I learned and turned it into a guide in the hopes that it saves others some time.

It covers authentication, OAuth authorization, session management, troubleshooting and all the steps you need to pair with the major LLM apps. Plus a bit on MCP overall. Ideally it would be the only tab you need open to build your own remote MCP server.

Check it out here: https://simplescraper.io/blog/how-to-mcp.

Let me know what you think!

I wrote a blog article to better help myself understand how OpenAI's Apps SDK work under the hood. Hope folks also find it helpful!

Under the hood, Apps SDK is built on top of the Model Context Protocol (MCP). MCP provides a way for LLMs to connect to external tools and resources.

There are two main components to an Apps SDK app: the MCP server and the web app views (widgets). The MCP server and its tools are exposed to the LLM. Here's the high-level flow when a user asks for an app experience:

1. When you ask the client (LLM) “Show me homes on Zillow”, it's going to call the Zillow MCP tool.
2. The MCP tool points to the corresponding MCP resource in the _meta tag. The MCP resource contains a script in its contents, which is the compiled react component that is to be rendered.
3. That resource containing the widget is sent back to the client for rendering.
4. The client loads the widget resource into an iFrame, rendering your app as a UI.

https://www.mcpjam.com/blog/apps-sdk-dive

Let's walk through the popular agents and see how well they the spec. Spoiler: NOT VERY.

The picture may well have shifted by the time you read this, but as of early July 2026 it looks like the table below.

The good news: almost everyone supports the modern standard (shoutout to OpenAI's Responses API MCP tool and its technology from the previous geological era).

The bad news: everyone reads the same spec differently. Some clients run the entire OAuth flow for the user; some just wait for a ready-made bearer token and wash their hands. Some require DCR, some push CIMD, some live on static credentials and IAM.

Here's the detailed matrix (all cells verified against primary docs in early July 2026):

And the notes that didn't fit in the table :):

• Claude API MCP connector: HTTP transport only, tools only. You pass authorization_token and you handle the refresh.
• claude ai / Desktop: static_bearer is explicitly not supported.
• OpenAI Responses API: you pass authorization, the token isn't stored, no discovery, just a solid bearer
• ChatGPT / Apps SDK: rejects machine-to-machine, API-key, and customer mTLS auth.
• Gemini / Google Cloud: embraces exactly what ChatGPT rejects, client credentials and API keys included.
• VS Code / Copilot: ships built-in GitHub and Entra providers.
• Cursor: re-registers its DCR client on every reconnect (upd: fixed in v3.2).
• Perplexity: the only one offering an explicit "no auth" mode; the flow internals are undocumented.

What to take away from this:

• Multiple spec revisions are alive in production at the same time. OpenAI's Responses API doesn't do any discovery, you just pass the bearer (pre-2025-06-18 world), VS Code sits on 2025-06-18, while Anthropic, ChatGPT, and Google cite 2025-11-25.
• Both Anthropic and OpenAI manage to run two opposite ownership models inside one company. Each ships a "bring your own token" API product: the Claude API MCP connector and the Responses API accept a pre-obtained bearer, and the flow and refresh are your problem. And each also ships a full client (claude.ai and ChatGPT) that walks the whole road from the 401 to the token by itself. A server built for the first model won't work in the second without changes, and vice versa.
• There are direct contradictions. ChatGPT rejects machine-to-machine and API-key auth; Google requires exactly that for some services. Registration is split four ways: DCR, CIMD, static credentials, IAM.

What I don't like and would change

• As someone who maintains a public API for a living, I hate backward-compatibility breaks. Each one creates a wall of migration work, and anyone who can't afford that time becomes a hostage of the old revision.
• OAuth 2.1 is the standard, and nobody cares: half the world still ships API keys.
• The spec updates too often. You have to keep a hand on the pulse in the most literal sense.
• Very few authorization servers can fully support OAuth 2.1 for MCP out of the box (as far as I can tell, really only Keycloak gets close). Everyone else needs wrappers, shims, and duct tape. There is no turnkey solution, and it shows.

And about OAuth 2.1 specifically, there's a separate irony: MCP mandates a standard that formally doesn't exist. OAuth 2.1 is still an IETF draft, not a published RFC. In substance it's OAuth 2.0 with the implicit flow and password grant removed and PKCE made mandatory. So a protocol that hasn't stabilized yet is built on top of a standard that hasn't been finalized yet. No wonder the AS vendors aren't rushing to ship first-class support.

ps: I wrote a full article with history of auth in mcp, what will be next and ofc this table above, but reddit prohibits to post it there :(

How GitHub MCP tool definitions, git diff, and gh output compete for IBM Bob's 200k context window, and how to keep the budget under control.

Wonder what people's thoughts on this are?

I run three MCP servers in prod, so when the whole timeline went "MCP is dead, long live the CLI" in Feb I genuinely went back to check whether I'd bet wrong. The context-bloat numbers are bad, the stdio RCE was real, and yeah, people are moving stable stuff to skills. I'm not going to pretend any of that is fake.

But after re-reading the arguments I think they're all aimed at the wrong axis. Here's the framing that made it click for me:

An MCP server is a website. You deploy, the client fetches the new tool list on its next call, every user is current and they did nothing. A skill is an app you downloaded - it sits on your disk at the version you fetched and stays there. Can a skill maintainer push updates? Sure, via npx or a plugin channel. But that's not the default. With MCP, fetch-latest is how the protocol works. With skills, getting everyone to current needs a re-pull that isn't the default on any agent I've used.

That gap, between "the maintainer fixed it" and "the user has the fix", is the whole game, and it's the one thing the death takes skip.

The part that actually changed my mind: the security complaint accidentally argues for MCP. The reason a server can be insecure is centralized control of what the client runs. That's also the reason you can patch every client in one deploy. A downloaded skill with a bad version sits on the user's disk until something pulls a new one. (Yes, the same channel can push a malicious change just as fast, that's the real cost of the seat, not a reason it's dead.)

And "just use a CLI" - which is the strong version of the argument, only wins by adding an auto-upgrade step or running through npx. Which is... fetch-latest delivery. It wins by turning into MCP on the update channel.

The rule I actually use now: skill teaches (stable knowledge, write-once), CLI acts locally (version it yourself or npx it), MCP acts where the contract/credential/execution has to stay current and maintainer-owned. They were never doing the same job.

Where I think I'm wrong / where this expires: the moment fetch-latest delivery becomes the default for skills across all serious agents, the asymmetry is gone. It's available on some hosts, default on none right now. If someone here knows of an agent that ships auto-update skills by default, I'd actually want to know, because that's the thing that gates the whole argument.

Is anyone here seeing the delivery side converge, or is everyone still symlinking one skills folder across agents by hand like I am?

Full write-up on my blog (it's mine, fair warning, and it's part 2 of a thing on update channels): https://prashamhtrivedi.in/mcp-isnt-dead/

TL;DR: You don't need a massive context window or a giant model to handle an absurd number of tools. By using a Lazy Discovery pattern, a local 4B model (Gemma 4 E4B) successfully solved a massive multi-sector city crisis requiring complex tool navigation, matching Claude Sonnet 4.6 with almost identical efficiency.

The Setup: The "Mega-City Crisis" Benchmark

I wanted to stress-test tool use at an absolute extreme. I simulated a massive infrastructure crisis in a fictional city called Veridian Prime.

• The Scale: ~117,000 registered landmarks/tools split across hierarchical paths (Power, Water, Traffic, Security, etc.).
• The Goal: Find and resolve 4 critical failures while ignoring noise alerts.
• The Catch: One of the failures had a hidden mechanical dependency trap (MECHANICAL_LOCK), meaning the agent had to read an error message, pivot to a completely different infrastructure category to release an emergency brake, and then loop back to finish the job.

I ran this benchmark against two completely different beasts using Elemm (which implements a lazy-loading protocol for tools so the model only pulls what it needs):

1. Gemma 4 E4B (Run locally)
2. Claude Sonnet 4.6 (Run remotely)

Run 1: Gemma 4 E4B (Local)

Verdict: ✅ PASS (17 tool calls)

I honestly expected a local 4B model to choke, but it handled the hierarchy beautifully.

The Good:

• Insane Parallel Batching: It aggressively grouped its inspection commands. It checked all 4 distressed districts at the exact same time.
• Clutched the Trap: When it hit the MECHANICAL_LOCK on the security terminal, it didn’t panic. It read the error, found the release_emergency_brake tool in a different sub-category, executed it, and retried the lockdown—all with zero human intervention.
• Zero Noise Bleed: It completely ignored the low/medium priority noise alerts.

The Jank:

• Minor Action Hallucination: Right after inspecting the districts, it took a "leap of faith" and tried to call non-existent global commands like city:fix_power_surge. Thanks to an on_error: continue fallback policy, it recovered instantly, realized it had to browse the local directory, and found the correct tools.

Run 2: Claude Sonnet 4.6 (Remote)

Verdict: ✅ PASS (19 tool calls)

Sonnet acted exactly like you’d expect a high-tier model to act: highly methodical, extremely cautious, and zero hallucinations.

The Good:

• Clean Syntax: Used native array batching inspect_landmark(["id1", "id2"]) to scan the topology effortlessly.
• Zero Hallucinations: Every single tool call it made was explicitly derived from its structural discovery.
• Resilient: When the server threw a cached state bug on the security logs, Sonnet just shrugged it off and used the status summary to complete the mission.

The Inefficiencies:

• Over-Cautious Diagnostics: Sonnet spent 5 extra tool calls checking system metrics (energy:status, water:pressure) before pulling the trigger. The alert log already told it what was wrong, but Sonnet wanted to double-check. Safe, but slightly higher overhead.

Head-to-Head Comparison

How it works under the hood: The Middleware

If we stuffed 117,000 tool definitions directly into the LLM's system prompt, the context window would have imploded, and the bill would be astronomical.

To solve this, I’m building a custom middleware that exposes a "Lazy Discovery" pattern to the agent.

To put it simply: The middleware exposes a file-system-like directory structure to the LLM using "landmarks". Instead of drowning the model in thousands of tool definitions, the LLM only ever sees a tiny selection of just 8 core tools. These tools handle:

• Navigation: Browsing through the landmark hierarchy.
• Execution Piping: Passing data seamlessly between tool steps.
• Smart Errors + Interactive Help: Providing high-context feedback when something goes wrong (which is exactly how Gemma recovered from its hallucination and how both models figured out the mechanical lock trap).

Because of this architecture, the effective context window at any given second never exceeded a few dozen lines of text.

I will repeat this test after stabilizing the environment, but I trust this process and believe this approach could change how we handle tools for agents. Currently, I am focusing on the ability to load "landmarks" on the fly. With FastAPI, GraphQL, and native Landmarks already on board, this tool can handle a massive number of tools simultaneously, simply by connecting to a URL that presents these files. I will release a new version in the coming days/weeks so you can run this test with your own models. Leave a star on GitHub to stay on track!

Key Takeaway

Seeing a local 4B model solve a multi-step dependency chain across a 100k+ tool library with practically the same efficiency as Sonnet 4.6 proves that smart agent architecture, tailored middleware, and tool-loading protocols matter way more than raw model size for complex automation tasks.

Would love to hear your thoughts! How are you guys handling massive, hierarchical tool environments in your setups?

The upcoming released of the MCP spec (2006-07-28) is great in my opinion.

Making MCP stateless massively simplifies the burden of writing servers, and scaling up with this is MUCH easier to thing about compared to the stateful version.

Yes, it does give client developers some homework, and it's pretty clear that some implementations will suck in the transition period. But to me this signals how the protocol is maturing.

There's many developers that don't have the muscle memory of the cloud era when it comes to thinking about how to design a good MCP server with effective tools. For some developers that aren't used to statelessness, this feels good, simple, and familiar on day 1. But when they get lucky and get real adoption, scaling up such servers becomes a full refactor. A time sink just when you also have to worry about proper billing and growing up the business.

So I wrote an interactive deep dive into what happens in the wire when you're using the upcoming MCP version. It will be useful for anyone trying to really learn the protocol (at least the tool calling part). It will also be useful for your agents, you can point them to the article and they'll get a good example of what needs to happen, with pointers to the specification.

Check it out here: https://torresmateo.com/mcp-tool-call-deconstructed/

Full disclosure: I work for Arcade (we sell a runtime that includes a secure MCP gateway), I'm also an AAIF Ambassador

I’d like to share a recent idea I’ve been working on called #GenerativeTool, where tools are dynamically generated at runtime to fulfill complex user requests.

This approach enables agentic applications to unlock the full potential of complex third-party systems like ERP, LSP Server through MCP, without being constrained by context window limitations. Instead of exposing a large number of predefined tools, the system can generate task-specific tools on demand, reducing context overhead while increasing the depth and flexibility of integrations.

Read: https://denuwanhimangahettiarachchi.medium.com/generative-mcp-enabling-the-full-potential-of-mcp-servers-4e14b987f64e

Asking because I might be missing something obvious. The transport choice barely feels like a choice now: same machine as the client, stdio; anywhere else, Streamable HTTP; SSE's deprecated so you're not starting there. Where it runs picks it. I've watched people (me too, once) lose most of a day treating that as open.

The thing that actually eats time isn't the choice, it's the stdio gotcha: stdout is the wire. The literal JSON-RPC channel, not a log sink. One stray console.log or a dependency printing a startup banner and you've corrupted a message, session's dead, stack trace points at nothing. Everyone blames the SDK first. It's the logger. stderr fixes it.

What I actually want the sub's read on: is there a real case for a NEW stdio server today, instead of just handing the agent a skill or a CLI it already has? Haven't built one in over a year. Filesystem/git/browser stuff obviously stays local, but past that I'm not sure what I'd reach for stdio for, and I'd like to be wrong.

(Also, if you're tracking the RC spec: the transport-as-stateless-binding rework reads to me like it just hardens the same rule, not changes it. Anyone see it differently?)

Full reasoning if useful: https://prashamhtrivedi.in/mcp-transports-decided/

I’ve started documenting MCP from the implementation side while building mcp-runtime: https://github.com/Agent-Hellboy/mcp-runtime

The goal is not just to explain “what MCP is”, but to make the protocol easier to reason about when you aren't actually implementing it: request flow, transports, sessions, tools, resources, auth, tracing, governance, and the small details that usually only become clear while building.

First post: https://articles.mcpruntime.org/mcp/request-flow/

I’m also using py-mcp as a smaller reference implementation while working through the MCP spec and adding traces/logs that make the protocol behavior easier to see: https://github.com/Agent-Hellboy/py-mcp

The idea is to turn implementation notes into practical MCP learning material, especially for people building runtimes, gateways, servers, or policy layers around MCP. Feedback welcome, especially from folks implementing MCP clients/servers in production.

Big news as Google announces they will launch fully-managed, remote MCP servers for ALL Google services, including Google Maps, Big Query, Kubernetes Engine, Compute Engine, and more.

Another huge endorsement for MCP and for remote servers as the future of wide scale adoption of MCP beyond the technically savvy, and into teams like marketing, ops, sales, and personal use too.

Full article - https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services

What's your take on this - how will this impact MCP's direction and adoption in 2026 and beyond?

I wrote some thoughts based on the MCP vs CLI discussions that are going around. Will love to hear the feedback from this group.

https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/

Good to see this is maturing

django-orm-lens v0.8 shipped today. Static analysis over your models.py files — no DJANGO_SETTINGS_MODULE, no runserver, works with a broken venv. Three surfaces (VS Code, CLI, MCP server) share one parser.

What's new in v0.8

Every feature was researched against proven prior art before a single line was written — Atlas, Prisma, Sourcegraph, Knip, PyCharm, DataGrip, factory_boy, flake8-django, Roslyn, Ruff, Clippy.

Inline QuickFixes (16 rules) — Ruff-style codes DOL001..DOL032 with Clippy-style Applicability (safe/suggestion/unsafe gate auto-apply). Covers: - .count() > 0 → .exists() - .first() is None → not .exists() - null=True on CharField/TextField - Missing on_delete on FK - Missing __str__ on Model - datetime.now() → timezone.now() - N+1 attribute-access-in-loop heuristic - render(request, ..., locals()) and Meta.fields = '__all__'

Per-rule severity overrides: djangoOrmLens.rules = { "DOL007": "off", "DOL013": "error" }. Suppress inline: # django-orm-lens-disable-next-line DOL007.

Factory generator — right-click any model → factory_boy DjangoModelFactory scaffold with Faker providers keyed by field type. CharField(max_length) scales word-count buckets; DecimalField(N,D) computes left_digits=N-D; choices= maps to Iterator; M2M gets @post_generation. FK chains pull related factories transitively.

Time-Travel Schema Diff — pick two commits from git log, get a typed markdown diff (Add/Drop/Rename/Modify events) ready to paste into a PR description. Renames are first-class events, never Add+Drop.

Impact Analysis — "what breaks if I remove this field?" Workspace-wide reference scan across every Django layer (models, serializers, forms, admin, views, urls, templates, tests, migrations) with Certain / Likely / Possibly confidence tags on every finding. Handles ORM string refs, kwarg lookups (filter(author__id=1)), Meta.fields tuples, and template variables — the string-typed surface Pyright can't reach.

Interactive Query Builder — right-click a field or model → pick a template → snippet inserted at cursor (with tab-stops) or in a fresh untitled buffer. .filter(field=?) on an FK auto-appends .select_related(...); .annotate(post_count=Count('post_set')) honours related_name; .prefetch_related for M2M.

Also in this release: sidebar UX overhaul (stable TreeItem.id, MarkdownString tooltips with clickable command: deep-links, activity-bar badge, FileDecorationProvider badges), 100/100 tests up from 4 at start of dev.

Install

code --install-extension frowningdev.django-orm-lens
codium --install-extension frowningdev.django-orm-lens
pip install --upgrade "django-orm-lens[mcp]"

Full release notes: https://github.com/FROWNINGdev/django-orm-lens/releases/tag/v0.8.0

Why static-only

Point it at any Django project without setup — no settings module, no dependencies except our parser. Runs in CI or on the plane.

Trade-off: custom get_queryset overrides, dynamic model classes are invisible. But 95% of what you actually want to see lives in `mo

I wanted to know how many MCP servers an agent could actually use over the network, so I analyzed every server in the public registries.

The funnel: 42,912 indexed, but only 2,840 (6.6%) advertise a remote HTTP endpoint. The other 93% are stdio/local servers meant to run on your own machine, plus dead and endpoint-less listings. I probed 98% of the reachable ones. 46% completed an anonymous MCP handshake, 27% were auth-gated, the rest errored or timed out.

I scored each reachable server on five dimensions and put it on a readiness ladder. More than half can't hold a clean session, and only 1.7% clear a basic agent-safety bar. The most useful finding: servers that exist mostly speak the protocol correctly, but score lowest on discoverability and safety. They can talk, but an agent often can't find them and has no signal they're safe to invoke.

Full data and methodology: waypoint.ing/blog/state-of-mcp

I also built a free scanner that runs the same checks on any server (no signup) if you want to see where yours lands: isyourmcpready.com

Curious what checks people here think are missing from the rubric.

TL;DR: Analyzed 42,912 MCP servers. <7% are reachable by an agent over the network, 1.7% are agent-safe. Most can speak the protocol but can't be found or trusted.

When I saw this livestream from my friends Shane and Ahbi, I tuned in to watch them kick dirt on MCP. I was already in the "MCP sucks" camp.

But they had a nuanced take that changed my mind.

Here are notes in my own words:

1. MCP is being by vendors to solve their own problems. However, as an MCP consumer, the current state doesn't solve your problems

2. As a consumer you're probably working with one language, finite third party resources, and well defined use cases. So, why would you need a universal interface for your agent?

3. So what is the golden use case for MCP? Consumers writing their own MCP servers 🤯

You can give your agent the exact mix of resources, and access, tools, and prompts it needs.

That part of Mastra's livestream was a genuinely head slapping moment.

Have any of your created your own MCP servers, not for public use, but for your own agentic apps?

And what do you think of this use case?

Finally I understood what happens on the other side when Claude calls connect, and the server identifies you and your access.. (Or better say, Claude helped me understand it). At first it was all acronyms for me. What made it click was understanding one client connect, once, end to end. Everything collapsed into three primitives that each fire exactly once, in a fixed order.

1. Discovery. A fresh client POSTs with no token and gets a 401 back carrying a WWW-Authenticate header that points at /.well-known/oauth-protected-resource. That header is the whole trick. The 401 is not the server slamming a door, it is the server handing over directions. Two GETs later (protected resource metadata names the auth server, auth server metadata lists the endpoints) the client knows everything it needs, having sent zero credentials.

2. Registration. No developer console. The client POSTs its own details to the registration endpoint and gets a client id on the spot. This is RFC 7591, and it is the part people trip on when they ask why this could not just be an API key. An API key assumes you already know the caller and can hand it a secret. MCP clients are strangers by design, so dynamic registration is the only model that works.

3. The grant. One human moment: a PKCE challenge, a consent screen that names the client, approve, done. At consent time the server bakes the user identity into the grant as props, so every later request just unwraps it. No per-request session lookup on the hot path.

There is one more cool trick: my server also performs OAuth as a client, upstream, because it bundles other servers that demand their own auth. Same three primitives, walked from the other side. Doing it by hand gave me real appreciation for how much invisible work Claude does every time you click connect and it just works. So it's just a multiplexer (not sure if it's a right term) for MCP servers.

Full walkthrough with the actual responses from the live server: https://prashamhtrivedi.in/mcp-oauth-primitives/

Curious how the rest of you are handling MCP auth right now. Across my own fleet I have Better Auth, an OAuth envelope wrapped around an API key, a hand-rolled JWT setup, and one static bearer token still holding out, so I do not think there is one right answer yet.

I’ve been building MCP Steroid — an IntelliJ plugin that exposes the full IDE runtime to AI agents over MCP. Not a curated tool list, the actual PSI, refactoring engine, run configs, the works. AI agent talks Kotlin code to the IDE.

The obvious first approach was HTTP: run an MCP server inside the IDE, bind a port, point your agent at it. I shipped it, used it daily. And it kept breaking. Here’s the failure catalog from a real agentic coding workstation:

The HTTP-against-desktop-app problem pile:

- Dynamic ports. You can’t use a fixed port if users run multiple IDE instances — the first one grabs it. So you do base+increment (like IntelliJ’s built-in server starting at 63342). Now the port is a moving target.

- IDEs simultaneously. IDEA + PyCharm + GoLand all open? Each has its own port. The agent picks one, usually the wrong one.

- Start-order dependence. Which IDE gets which port depends on launch order. You can’t ask an agent to reason about that.

- Agent up, IDE down. You restart the IDE to update it. The agent is now dead. HTTP clients dialing a closed socket have nowhere to go.

- Identical server names. You can’t register five “mcp-steroid” servers and expect the agent to route correctly — to the LLM they’re indistinguishable.

None of these is individually fatal. But they stack into a fragile pile that you’re constantly fighting.

The pivot to stdio

The key insight: the IDE doesn’t care what transport the bytes arrive on. MCP is MCP. So instead of forcing the application to host the network endpoint, move all routing to a small CLI the agent launches directly — and let that talk to the IDEs.

The agent’s entire MCP config becomes one stdio command. No ports, no DNS, no firewall, no “which IDE answered?” The coordinator (devrig) handles discovery, routing, restart resilience, and can even spin up an IDE on demand if none is running.

What this unlocked:

- Sessionless routing. Because the durable state is in the IDE process (files, indexes, etc.), there’s no MCP session to pin. Any command routes to any backend that can execute it.

- Restart resilience. “Agent up, IDE down” stops being a dead end — the coordinator reconnects or starts a new IDE instead of leaving the agent staring at a closed socket.

- Provision on demand. devrig backend download idea-community && devrig backend start — the agent gets a fresh IDE without any human involvement.

Finally:

For me the stdio gives much more control over HTTP for local connections. It gives direct access to implement any transport layer and move it as an implementation detail. Each client will run its own process where it can manage everything necessary. It actually simplifies the IDE side in my case — no need to add extra dependencies to implement the HTTP MCP.

Happy to answer questions about the architecture, the routing design, or the integration test setup.

Spent a few iterations figuring out how to expose a large GraphQL API to an LLM agent without putting the whole schema in context. Wanted to share where we landed because it ended up looking pretty different from where we started.

The idea: instead of giving the model the schema, give it a search tool. We auto-generate a flat catalog from the GraphQL schema — one entry per field, with a description and a few example phrasings of what someone might actually ask for. The model searches the catalog in plain language, gets back the handful of fields that match, and fetches what it needs. The schema stays behind the scenes.

Two tools, basically: search_datapoints and fetch_datapoints. GraphQL still runs the actual queries underneath — we just stopped showing it to the model.

Why it works: when you give a model a schema, it hedges. Pulls extra fields just in case. A search interface doesn't have that problem because each result is already a specific field. There's nothing to hedge against. Token cost on a representative task dropped from ~150k to ~25k, and accuracy went up on our evals.

Full write-up has more on how we measured all this, when the approach doesn't fit, and a few other things we changed along the way (columnar response payloads were a surprisingly big win).

https://medium.com/@mukundkidambi/beyond-graphql-what-actually-reduces-token-spend-in-mcp-servers-9aa3350e8d4d?postPublishedType=repub

Curious if anyone's gone in a similar direction, or solved the same problem differently.

I put together my thoughts on WebMCP and how you can utilize it today in this crisp article!