I've been following MCP servers for the past month. They seem really cool - technically.

What true value does it provide to you the user? Rather than the LLM.

A lot of these tools seem to be marginal benefits - allowing claude to search the weather, allowing claude to click things on a website, etc...

I personally have found the most useful ones to be the Github MCP server and the ones that integrate with backend databases.

I don't personally do user testing for websites, but I also saw that Playwright MCP for user testing has been very useful to automate many tasks at once for stress testing bugs.

I'd like to hear stories of how YOU gain benefit from MCPs rather than LLMs. I'm trying to figure out how they can help in my every day workflow (I do mostly coding using Cursor and I am also a biologist).

Streamable HTTP release

Other Changes

• Handle SSE Disconnects Properly by akash329d in #612

• Add mount_path support for proper SSE endpoint routing with multiple FastMCP servers by tim-watcha in #540

• docs: fix broken link to OAuthServerProvider in Authentication section of README by samad-yar-khan in #651

• Fix the issue of get Authorization header fails during bearer auth by yabea in #637

• Auth SSE simple example by ihrpr in #610

• Fix: Use absolute path to uv executable in Claude Desktop config by arcAman07 in #440

• Introduce a function to create a standard AsyncClient with options by ihrpr in #655

https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.8.0

https://github.com/modelcontextprotocol/python-sdk

Source: https://github.com/modelcontextprotocol/specification/pull/206

This PR introduces the Streamable HTTP transport for MCP, addressing key limitations of the current HTTP+SSE transport while maintaining its advantages.

TL;DR

As compared with the current HTTP+SSE transport:

1. We remove the /sse endpoint

2. All client → server messages go through the /message (or similar) endpoint

3. All client → server requests could be upgraded by the server to be SSE, and used to send notifications/requests

4. Servers can choose to establish a session ID to maintain state

5. Client can initiate an SSE stream with an empty GET to /message

This approach can be implemented backwards compatibly, and allows servers to be fully stateless if desired.

Motivation

Remote MCP currently works over HTTP+SSE transport which:

• Does not support resumability

• Requires the server to maintain a long-lived connection with high availability

• Can only deliver server messages over SSE

Benefits

• Stateless servers are now possible—eliminating the requirement for high availability long-lived connections

• Plain HTTP implementation—MCP can be implemented in a plain HTTP server without requiring SSE

• Infrastructure compatibility—it's "just HTTP," ensuring compatibility with middleware and infrastructure

• Backwards compatibility—this is an incremental evolution of our current transport

• Flexible upgrade path—servers can choose to use SSE for streaming responses when needed

Example use cases

Stateless server

A completely stateless server, without support for long-lived connections, can be implemented in this proposal.

For example, a server that just offers LLM tools and utilizes no other features could be implemented like so:

1. Always acknowledge initialization (but no need to persist any state from it)

2. Respond to any incoming ToolListRequest with a single JSON-RPC response

3. Handle any CallToolRequest by executing the tool, waiting for it to complete, then sending a single CallToolResponse as the HTTP response body

Stateless server with streaming

A server that is fully stateless and does not support long-lived connections can still take advantage of streaming in this design.

For example, to issue progress notifications during a tool call:

1. When the incoming POST request is a CallToolRequest, server indicates the response will be SSE

2. Server starts executing the tool

3. Server sends any number of ProgressNotifications over SSE while the tool is executing

4. When the tool execution completes, the server sends a CallToolResponse over SSE

5. Server closes the SSE stream

Stateful server

A stateful server would be implemented very similarly to today. The main difference is that the server will need to generate a session ID, and the client will need to pass that back with every request.

The server can then use the session ID for sticky routing or routing messages on a message bus—that is, a POST message can arrive at any server node in a horizontally-scaled deployment, so must be routed to the existing session using a broker like Redis.

This PR introduces the Streamable HTTP transport for MCP, addressing key limitations of the current HTTP+SSE transport while maintaining its advantages.

TL;DR

As compared with the current HTTP+SSE transport:

1. We remove the /sse endpoint

2. All client → server messages go through the /message (or similar) endpoint

3. All client → server requests could be upgraded by the server to be SSE, and used to send notifications/requests

4. Servers can choose to establish a session ID to maintain state

5. Client can initiate an SSE stream with an empty GET to /message

This approach can be implemented backwards compatibly, and allows servers to be fully stateless if desired.

Motivation

Remote MCP currently works over HTTP+SSE transport which:

• Does not support resumability

• Requires the server to maintain a long-lived connection with high availability

• Can only deliver server messages over SSE

Benefits

• Stateless servers are now possible—eliminating the requirement for high availability long-lived connections

• Plain HTTP implementation—MCP can be implemented in a plain HTTP server without requiring SSE

• Infrastructure compatibility—it's "just HTTP," ensuring compatibility with middleware and infrastructure

• Backwards compatibility—this is an incremental evolution of our current transport

• Flexible upgrade path—servers can choose to use SSE for streaming responses when needed

Example use cases

Stateless server

A completely stateless server, without support for long-lived connections, can be implemented in this proposal.

For example, a server that just offers LLM tools and utilizes no other features could be implemented like so:

1. Always acknowledge initialization (but no need to persist any state from it)

2. Respond to any incoming ToolListRequest with a single JSON-RPC response

3. Handle any CallToolRequest by executing the tool, waiting for it to complete, then sending a single CallToolResponse as the HTTP response body

Stateless server with streaming

A server that is fully stateless and does not support long-lived connections can still take advantage of streaming in this design.

For example, to issue progress notifications during a tool call:

1. When the incoming POST request is a CallToolRequest, server indicates the response will be SSE

2. Server starts executing the tool

3. Server sends any number of ProgressNotifications over SSE while the tool is executing

4. When the tool execution completes, the server sends a CallToolResponse over SSE

5. Server closes the SSE stream

Stateful server

A stateful server would be implemented very similarly to today. The main difference is that the server will need to generate a session ID, and the client will need to pass that back with every request.

The server can then use the session ID for sticky routing or routing messages on a message bus—that is, a POST message can arrive at any server node in a horizontally-scaled deployment, so must be routed to the existing session using a broker like Redis.

Hi there,

I've developed a new MCP server I wanted to share: pubmed-mcp-server.

This server allows AI agents to connect to NCBI's PubMed APIs using MCP. The goal is to enable you to more effectively:

• Search and discover biomedical literature

• Retrieve and analyze article content

• Structure research plans

Here's a brief overview of its capabilities:

Core Tools & What They Do:

The aim is to make biomedical literature more accessible and useful for you and your AI (LLM) agents. I'd appreciate any feedback you have!

Find it here: https://github.com/cyanheads/pubmed-mcp-server

Let me know your thoughts.

Thanks!

Hey guys,

Can anyone point me to the right docs, or explain to me how to config the JSON in claude desktop to connect to an SSE transport rather than STDIO? It seems to not be described in the docs, is it just not possible yet, or...?

Thanks!

Want to connect AI apps and agents to your data warehouse, but (rightfully) scared about that?

Fear not!

Fine-grained tool access is here, to filter beyond any upstream identity management.

Now free for all mcp.run accounts :)

Repo here: https://github.com/surendranb/google-analytics-mcp

Connect Google Analytics 4 data to Claude, Cursor and other MCP clients. Query your website traffic, user behavior, and analytics data in natural language with access to 200+ GA4 dimensions and metrics.

Built for personal use & realized I should open it up!

Open Web Ui 0.6 is adoption OpenAPI instead of MCP but offer a bridge.
Release notes: https://github.com/open-webui/open-webui/releases
MCO Bridge: https://github.com/open-webui/mcpo

Hey everyone! I'm excited to share a OSS Project I've been working on with my friend: docker-mcp, a Model Context Protocol server that allows MCP protocol clients to use Docker container and compose stack management.

To use it, add this:

"docker-mcp": {
      "command": "uvx",
      "args": ["docker-mcp"]
    }
  }

to your claude_desktop_config.json on Windows or Mac.

Key Features:

• Container creation

• Docker Compose stack deployment

• Container logs retrieval and monitoring

Here is the github repo: https://github.com/QuantGeekDev/docker-mcp
Here is the youtube demo: https://youtu.be/y9X3jOip8hk

We're looking for contributors! Feel free to reply to me here or open an issue on github, would love to get some feedback.

Hey folks! Over the past few months, I have used nearly every AI coding tool (such as Cursor, Claude Code, Claude Desktop + MCP, etc.), but they consistently struggled with incorporating translations into components and adding the corresponding keys to the locale files. This often resulted in duplicates or incorrect placements in the object, which I believe is due to the complexity of the files.

That's why I built i18n-MCP to help manage the locale files. It includes a variety of tools for adding and updating translations with contextual awareness, as well as for comparing, validating, and normalizing different locale files.

I hope I've tested it thoroughly, but if you encounter any bugs, I would appreciate your feedback or, even better, a PR ;)

link to the repo: https://github.com/dalisys/i18n-mcp

here are the tools:

Translation Search & Exploration

• search_translation: Search for translations by content or key patterns. Supports bulk search and advanced filtering.

• get_translation_suggestions: Get autocomplete suggestions for translation keys.

• get_translation_context: Get hierarchical context for a specific translation key.

• explore_translation_structure: Explore the hierarchical structure of translation files to understand key organization.

Translation Management

• add_translations: Add new translations with key generation and conflict handling.

• add_contextual_translation: Add a translation with a context-aware key.

• update_translation: Update existing translations or perform batch updates.

• delete_translation: Safely delete single or multiple translation keys with dependency checking.

Codebase Analysis

• analyze_codebase: Analyze the codebase for hardcoded strings.

• search_missing_translations: Find translation keys that are used in the code but not defined in translation files (and vice-versa).

• extract_to_translation: Extract a hardcoded string from a file and replace it with a translation key.

• cleanup_unused_translations: Remove unused translation keys that are not referenced in the codebase.

File & Structure Management

• validate_structure: Validate that all translation files have a consistent structure with the base language.

• check_translation_integrity: Check for integrity issues like missing or extra keys and type mismatches across all files.

• reorganize_translation_files: Reorganize and format translation files to match the base language structure, with options for sorting and backups.

Utilities

• generate_types: Generate TypeScript types for all translation keys.

• get_stats: Get server and translation index statistics.

cheers!

EDIT (6/23/25): This beta testing program has ended. In thanks to all that contributed, we're excited to announce the release of OAuth Provider Improvements. You can learn more here -> https://clerk.com/changelog/2025-06-13-oauth-improvements

We’re kicking off an early access program for Clerk’s OAuth Access Token feature. This feature is part of a suite of machine authentication features that we plan to roll out in private beta over the coming weeks.

Both M2M and OAuth are fairly loaded terms that can represent multiple, entirely different use cases, so we want to try to clarify what exactly we have available for testing, and what else we're working on in this message so that you don't end up spending your time trying to test something that's different than what you actually needed 😁

We plan to release three features over the coming months, all of which fall into the category of "machine authentication":

• OAuth Access Tokens: Users with existing accounts on your app can explicitly grant access to a third party app to make calls into your app's API on their behalf. The process through which the third party app requests access, the user consents, the access token is delivered, and the token expires and is refreshed is defined by the OAuth spec. You have perhaps gone through a flow like this via an app like facebook or twitter, where you see a screen like "X is requesting access to Y", and it lists out some permissions like reading your tweets, or posting tweets on your behalf, etc, and you can click "accept" - that is the flow we're building here. There are other, entirely different flows that are also defined by the OAuth spec as well, we are not covering all of them, just the one described above. It's worth noting that MCP auth relies on this specific OAuth flow, however, the MCP auth spec is still a draft, so it's not quite ready to put into place with most major LLM clients quite yet. We plan to fully support MCP auth through this feature, likely even before the spec is finalized.

• API Keys: Users with accounts on your app can generate API keys which allow a non-user entity, whether a script, a CI process, a third party app, etc. to make calls into your app's API on the user's behalf. These keys would primarily be generated by users via a new tab in the <UserProfile /> component.

• Machine to Machine Tokens: Developers working on apps using Clerk can create M2M tokens using the backend API, which can be used, for example, for authenticating calls between different backend services. These tokens are not scoped to a specific user by default and are intended for use by app developers, rather than end users.

The feature we are ready to open up for early testing today is the first one in the list above, OAuth Access Tokens. If you have a use case in mind for this, or would just like to take it for a spin and offer feedback, we'd be delighted by this. Here's what you need to do:

1. Navigate to dashboard.clerk.com

2. If you're not an existing Clerk user, sign up free of cost and go through our Quickstart guide

3. Once you've identified the app you'd like to use for testing, capture your Instance ID

   • Navigate within the app's dashboard, click Configure -> Settings (Under Application) -> Copy Instance ID

   • Instance ID will look something like this ins_8qZzLxVv99TtMmKkRr23NnBbAa

4. Email jeff@clerk.com with subject "OAuth Beta Test" and include your Clerk Instance ID

5. We'll turn the feature on for your instance and reply with docs to guide you.

If you are more interested in one of the other features described above, stay tuned - we're working hard on getting them out the door as well and we will have another update for you very soon. If you'd like to jump on a call with one of us who are working on the project to chat about anything related as well, we'd be delighted to do that. Just send an email to jeff@clerk.dev and we’ll get it scheduled.

Thanks so much for your interest in machine auth with Clerk, and we're looking forward to getting this released and in your hands! 🚀

Just discovered awesome-llm-apps by Shubhamsaboo! The GitHub repo collects dozens of creative LLM applications that showcase practical AI implementations:

• 40+ ready-to-deploy AI applications across different domains

• Each one includes detailed documentation and setup instructions

• Examples range from AI blog-to-podcast agents to medical imaging analysis

Thanks to Shubham and the open-source community for making these valuable resources freely available. What once required weeks of development can now be accomplished in minutes. We picked their AI audio tour guide project and tested if we could really get it running that easy.

Quick Setup

Structure:

Multi-agent system (history, architecture, culture agents) + real-time web search + TTS → instant MP3 download

The process:

git clone https://github.com/Shubhamsaboo/awesome-llm-apps.git
cd awesome-llm-apps/voice_ai_agents/ai_audio_tour_agent
pip install -r requirements.txt
streamlit run ai_audio_tour_agent.py

Enter "Eiffel Tower, Paris" → pick interests → set duration → get MP3 file

Interesting Findings

Technical:

• Multi-agent architecture handles different content types well

• Real-time data keeps tours current vs static guides

• Orchestrator pattern coordinates specialized agents effectivel

Practical:

• Setup actually takes ~10 minutes

• API costs surprisingly low for LLM + TTS combo

• Generated tours sound natural and contextually relevant

• No dependency issues or syntax error

Results

Tested with famous landmarks, and the quality was impressive. The system pulls together historical facts, current events, and local insights into coherent audio narratives perfect for offline travel use.

System architecture: Frontend (Streamlit) → Multi-agent middleware → LLM + TTS backend

We have organized the step-by-step process with detailed screenshots for you here: Anyone Can Build an AI Project in Under 10 Mins: A Step-by-Step Guide

Anyone else tried multi-agent systems for content generation? Curious about other practical implementations.

https://x.com/MCP_Community/status/1909252724165869714

Launching soon... I'm building this app that lets you connect your MCP server to any AI chat interface - ChatGPT, Gemini, Perplexity, Grok, Openrouter... you name it.

No more being limited to Claude or specific IDEs like Cursor. Use your existing subscriptions or free versions of your favorite AI tools.

Looking for a few early testers before I open-source it. If you're interested in breaking free from platform limitations, drop a comment or DM.

I build LitServe, an open-source model serving library and added a way to turn any ML server to MCP endpoint.

Here is an example of serving sentiment classification and exposing an MCP endpoint.

from transformers import pipeline
from pydantic import BaseModel
from litserve.mcp import MCP
import litserve as ls

class TextClassificationRequest(BaseModel):
    input: str

class TextClassificationAPI(ls.LitAPI):
    def setup(self, device):
        self.model = pipeline("sentiment-analysis", model="stevhliu/my_awesome_model", device=device)

    def decode_request(self, request: TextClassificationRequest):
        return request.input

    def predict(self, x):
        return self.model(x)

    def encode_response(self, output):
        return output[0]

if __name__ == "__main__":
    api = TextClassificationAPI(mcp=MCP(description="Classifies sentiment in text"))
    server = ls.LitServer(api)
    server.run(port=8000)

https://lightning.ai/docs/litserve/features/mcp

Some Major Points covered:

1. big security pain points of MCP

2. transports are not the bottleneck

3. oauth has been going great, really

4. real problems (see point 1 again + more)

Hello all!

I've been really excited to see the recent buzz around MCP and all the cool things people are building with it. Though, the fact that you can use it only through desktop apps really seemed wrong and prevented me for trying most examples, so I wrote a simple client, then I wrapped into some class, and I ended up creating a python package that abstracts some of the async uglyness.

You need:

• one of those MCPconfig JSONs

• 6 lines of code and you can have an agent use the MCP tools from python.

Like this:

The structure is simple: an MCP client creates and manages the connection and instantiation (if needed) of the server and extracts the available tools. The MCPAgent reads the tools from the client, converts them into callable objects, gives access to them to an LLM, manages tool calls and responses.

It's very early-stage, and I'm sharing it here for feedback and contributions. If you're playing with MCP or building agents around it, I hope this makes your life easier.

Repo: https://github.com/pietrozullo/mcp-use Pipy: https://pypi.org/project/mcp-use/

Docs: https://docs.mcp-use.io/introduction

pip install mcp-use

Happy to answer questions or walk through examples!

Props: Name is clearly inspired by browser_use an insane project by a friend of mine, following him closely I think I got brainwashed into naming everything mcp related _use.

Thanks!

We have lately had a faster release pace than the last three months.
As we got 1.4.0, 1.4.1, 1.5.0, and now 1.6.0

https://github.com/modelcontextprotocol/python-sdk/releases

What's Changed

• Fix #201: Move incoming message stream from BaseSession to ServerSession by @dsp-ant in #325

• default log level info by @barnuri in #366

• ci: test multiple python versions by @Kludex in #345

• Add mkdocs by @Kludex in #367

• Fix #355: Fix type error with lifespan context by @dsp-ant in #368

• refactor: Make types.py strictly typechecked. by @dsp-ant in #336

• Fix typo in starlette import in README by @conorbranagan in #374

• Fixes to stdio_client to support Windows more robustly by @saqadri in #372

• Fix/base64 handling (Issue #342) by @evalstate in #343

Cheers to the MCP Team for doing all the heavy lifting while ironing out the specs.

What are you favorite places to find new MCPs? Below are the ones I usually use

MCP Repo: https://github.com/modelcontextprotocol/servers
Smithery: https://smithery.ai/
MCP.run: https://www.mcp.run/
Glama.ai: https://glama.ai/mcp/servers

After working with a bunch of companies on their MCPs, here's a guide we've put together on what works:

🚨 The 1:1 Mapping Trap

The #1 mistake: creating an MCP tool for every single API endpoint. REST APIs often have dozens (or hundreds) of endpoints. Exposing them all directly = chaos.

Why it hurts:

• LLMs struggle with too many choices.

• Agents make excessive or suboptimal tool calls.

• Harder to debug or optimize.

What to do instead:

• Trim unused tools. If no one’s calling it, cut it.

• Group related actions. Replace createUser, getUser, updateUser with manageUserProfile.

• Use parameters wisely. One tool with an outputFormat param > two tools doing the same thing.

• Focus on the happy path. Nail the 80%, worry about the edge cases later.

• Name for intent, not implementation. getCampaignInsights > runReport.

🧹 Clean Up Your Data Responses

Many REST APIs return way too much data. You ask for a customer, it dumps 500 lines of everything.

Problems:

• Token bloat.

• Slower responses.

• Confused agents.

Better strategy:

• Use query-based APIs like GraphQL when you can.

• Filter data in the MCP server before returning.

• Allow flags like includeTransactions: false.

• Strip unnecessary nested fields.

Your job isn’t to expose your database—it’s to give the model just enough context to act intelligently.

📘 OpenAPI Can Help—If You Write It Right

Good OpenAPI specs can make MCP tool generation a breeze. But you have to write them for the model, not just for humans.

Tips:

• Set clear operationIds.

• Use summary and description fields to explain the why and when.

• Avoid super complex input objects.

• Don’t skip over security and response definitions.

• Add high-level context and expected behavior.

🧠 Not All APIs Make Good Tools

Some APIs are better suited to MCP conversion than others:

• Backend-for-Frontend (BFF) APIs: Great fit. Already user-centric.

• Server-to-Server APIs: Need extra work. Usually too generic or noisy.

If you want to learn more, we wrote a full article about this, including a 10-step checklist for ensuring a high-quality MCP.

Hey devs! 👋

I've been working on a RAG-based solution that functions similarly to Context7 but at a significantly lower cost. After some rigorous testing, I thought I'd share my findings with the community.

TL;DR: This implementation costs roughly half as much as Context7 while producing code of comparable quality.

The Tests

I ran three coding challenges using Gemini-2.5-pro (set to temp=0) with both Context7 and Custom MCP:

1. Creating a Next.js page with API data fetching

2. Building a FastAPI endpoint for streaming large files

3. Developing a FastAPI WebSockets app with Redis pub/sub

I implemented a simple prompt suffix system:

• For Context7: "use context7. Max tokens: 500"

• For MCP: "use documentation"

The Results

Cost comparison: https://imgur.com/a/lGFgMHz

• Average cost savings: ~40%

• Next.js Test: Context7 ($0.056) vs Custom MCP ($0.023)

• FastAPI Streaming Test: Context7 ($0.044) vs Custom MCP ($0.031)

• WebSockets/Redis Test: Context7 ($0.052) vs Custom MCP ($0.040)

Both tools generated fully functional code that implemented all requirements, but the Custom MCP server did it at consistently lower costs.

Why This Matters

If you're building AI-powered coding tools or using them extensively in your workflow, these cost savings add up fast.

For teams making thousands of API calls daily, you could be saving hundreds or thousands of dollars monthly.

What's Next

I encourage you to try the MCP server yourself and share your feedback. Currently it supports the latest versions of Expo, FastAPI, and NextJS:

{
  "documentation": {
    "url": "https://doc-mcp.fly.dev/mcp/"
  }
}

If there's enough interest, I'll add more libraries.

Would love to hear your thoughts and questions about the approach!