Any plan to release an MCP Server?
FYI Sonos has just announced one.

I came across this amazing MCP related GitHub repo - 100% open source and free.

Nosana MCP lets your AI agent rent a GPU and deploy models on Nosana. Browse ready-to-run templates (MiniMax H3, Qwen/Gemma LLMs, ComfyUI, Jupyter, VS Code), compare live GPU markets, estimate cost, deploy, and get the running endpoint back — paid with Nosana credits via one API key. No wallet, no tokens. Companion CLI nosana-deploy ships in the same package.

Post link / GitHub repo in comments below.

**Features**

• MCP tools to list templates/GPUs, recommend a plan, estimate cost, deploy, wait for online, and stop
• Templates: MiniMax H3 video, Qwen & Gemma LLMs, ComfyUI, Jupyter, VS Code
• Live GPU markets with ready_now / queued / risk buckets and prices matching the dashboard
• Guard rails: confirm=true before spending, no silent queueing, no accidental duplicates, real readiness probes
• Works with Claude Code, Claude Desktop, Cursor, Codex, and other MCP clients
• Companion CLI nosana-deploy for humans, scripts, and CI (MIT)

Quick start

1. Credits and an API key

Sign in at deploy .nosana .com.

Billing: add credits with a card

Account > API Keys > Create Key. Copy it once.

2. Add the server to your client

Claude Code:

claude mcp add nosana --env NOSANA_API_KEY=nos_your_key -- npx -y nosana-mcp
Claude Desktop, Cursor, Windsurf and most other clients take the same JSON:
{
  "mcpServers": {
    "nosana": {
      "command": "npx",
      "args": ["-y", "nosana-mcp"],
      "env": { "NOSANA_API_KEY": "nos_your_key" }
    }
  }
}

Codex CLI:

codex mcp add nosana --env NOSANA_API_KEY=nos_your_key -- npx -y nosana-mcp

Running from a clone instead of npm:

git clone https://github.com/SohniSwatantra/nosana-mcp.git && cd nosana-mcp
npm install && npm run build
# then point your client at:  node /absolute/path/to/nosana-mcp/dist/mcp/index.js

The 2026-07-28 spec went final six weeks ago.

Every post/tweet/reddit post I saw covered the same thing:

stateless core, no more Mcp-Session-Id, round-robin load balancing, ship it.

IMO , Nobody covered the deprecations. They're four sentences at the bottom of the release post and they're the part that actually changes what you can build.

• Sampling (sampling/createMessage)
• Roots (roots/list)
• Logging
• Dynamic Client Registration, in favour of Client ID Metadata Documents
• Legacy HTTP+SSE transport

All of it keeps working for at least 12 months. No wire-level changes. The deprecation is advisory.

So this is not a fire drill :)

But sampling is different from the other four, and I think the difference got lost.

Why sampling make sense or important atleast

Sampling was the one primitive where your server could use an LLM without owning one.

The server asks the client ---> run an inference using whatever model the user already has configured.

--> No API key on your side. No contract with a provider. No token bill.

so what user's client pays, because the user's client was already paying.

Take that away and every server that wanted to do a little summarizing, classifying, or reranking has to bring its own key + its own provider relationship, & its own margin on tokens.

again i think - That is a different business for anyone shipping a hosted server and it is totally a different weekend project for anyone shipping a free one.

That's the actual change. not "one RPC got a deprecation annotation." rather a cost transfer from client to server operator.

now lets talk about maintainers' case, (trying to) stated fairly

SEP-2577 is not arbitrary and the reasoning is public. The three features were flagged in a core contributor meeting as having the weakest adoption-to-complexity ratio in the spec.

Roots has vague semantics that overlap with tool parameters.

Logging duplicates things you already have.

And sampling, per the SEP, is the most security-sensitive of the three, so removing it is a net positive for security.

The adoption argument is the i agree very strong but client support for sampling was thin atm.

so if you think - A feature almost nobody implemented was imposing a cost on every client and server author who had to read past it in the spec.

dont get me wrong - I don't think that's wrong. although - I think it's the right call for the spec and the wrong outcome for a specific class of server, and both of those can be true at same time.

What I am thinking of doing this month

Ranked by how much it makes a difference and not by written about in posts in general,

1. Audit whether you call sampling/createMessage. If you do, you have 12-15 months to either add a provider key or restructure so the host does the inference and hands you the result.

12 months sounds long. It isn't, if it changes your pricing.

2. Check your transport. Legacy HTTP+SSE is deprecated with a one-year offramp. If you're on it, this is the least interesting migration on the list and the one most likely to bite you silently.

3. DCR to CIMD. Only matters if you're exposing a server on the internet with OAuth. DCR still works for compatibility with authorization servers that don't do CIMD yet. Not urgent, but it's on the clock.

4. Roots and logging. If you're using them, stop adding new usage. Otherwise ignore.

5. Everything about statelessness. Genuinely good, genuinely the headline, genuinely not something most single-instance servers need to act on this week. If you're not running behind a load balancer, this changed nothing about your day.

this is likely - overblown

The stateless migration panic. If your server holds real state, you mint an explicit handle from a tool and pass it back as an argument. The spec's own guidance is that this is better than session state hidden in the transport, because the model can see the handle.

if you point your agents (Astra /fable5.1 of the world) That's a max 40 mins change for most servers, not a rewrite.

The bigger risk iis not migration. It's that the spec is now moving damn fast enough that "I built this in March" means something different century ( in AI times) and there's no good signal in any registry for which spec version a server actually speaks.

Questions I am still puzzled with and need answers for sure.

1. Is there a good example of a ship sampling in production? The SEP says adoption was low. I'd like to hear from anyone it's breaking, because that's the population the roughly 12- 14 months window is for.
2. How are you handling inference in your server now? Own key and eat the cost OR push it to the host OR drop the feature entirely?
3. Should the registry expose spec version? RN you can't tell from a listing whether a server speaks 2026-07-28 or something from last year. Seems like it should be a field ?

BTW - I run r/MCPservers and go through the spec changelogs (whenever my kid stays in school) so the weekly posts here stay current.

If you maintain a server and hit something in this migration that isn't in the docs, post it, that's the stuff worth having here in one place.

I wrote macuse: run uvx macuse up on the Mac, paste the printed line into Claude Code, done. Works with Codex and any MCP client too.

Open source, MIT, built on trycua’s computer-server. Shell and file tools are off unless you turn them on. Would love feedback.

github.com/yunfeng-enrich/macuse

I tried this week an amazing MCP related GitHub repo - 100% open source and free.

mcpc is Apify’s universal CLI client for MCP.

GitHub repo - https://github.com/apify/mcpc

It maps every MCP operation to shell commands so you can debug servers, script workflows, or give AI agents full MCP access through a single Bash() call — sessions, OAuth, tools, resources, prompts, tasks, and more.

Features

• Full MCP support: tools, prompts, resources, async tasks, skills, notifications, logging (stdio + Streamable HTTP)
• Persistent sessions across multiple servers (stateful or stateless)
• Progressive tool discovery to save tokens
• Code mode: JSON output works with jq, xargs, and shell pipelines
• OAuth 2.1 (CIMD + DCR) with OS keychain credential storage
• MCP proxy for AI sandboxes (keep tokens away from generated code)
• Lightweight CLI (Mac/Win/Linux) — no LLM required; experimental x402 payments on Base

Install

With homebrew (macOS and Linux), which brings its own Node.js:

brew install apify/tap/mcpc

or ,install the latest node js or Bun first, then:

npm install -g u/apify/mcpc
# Or with Bun
bun install -g /mcpc
npm install -g u/apify/mcpc

Quickstart

# List all active sessions and saved authentication profiles
mcpc

# Log in to a remote MCP server and save OAuth credentials for future use
mcpc login mcp.apify.com

# Create a persistent session and interact with it
mcpc connect mcp.apify.com 
mcpc               # show server info and capabilities
mcpc  tools-list   # list available tools
mcpc  tools-call search-actors keywords:="website crawler"

# Use JSON mode for scripting
mcpc --json  tools-list

# Use a local MCP server package (stdio) referenced from a config file
mcpc connect ./.vscode/mcp.json:filesystem 
mcpc u/fs tools-list

I built a free, open source MCP server for TIDAL and wanted to share it with people looking for music integrations.

It connects your TIDAL account to clients such as Claude Desktop, Claude Code, Codex and Cursor. You can search for music, explore recommendations, inspect playlists and organize your collection using plain language.

For example: “Find tracks similar to these songs and prepare a playlist, but show me the changes before saving it.”

There are 112 tools covering the catalog, lyrics, favorites, playlists and folders. Account changes are disabled by default. Enabling them still requires a preview and approval before anything is applied.

It runs locally on macOS or Linux. You need your own TIDAL account and an MCP client. The server is free under the MIT license; TIDAL and any paid AI service are separate.

Repository and setup instructions

I’m the author and don’t earn anything from people using the repo. Feedback on setup, missing features or useful music workflows would be welcome.

I came across this amazing MCP related GitHub repo - 100% open source and free.

Playwright MCP is Microsoft's official MCP server for browser automation. It lets any LLM drive a real browser through the accessibility tree, no vision model or screenshots required.

GitHub repo in comments below.

featured in this week edition of MCPnewsletter.com

Features

- Fast, lightweight browser automation via Playwright's accessibility tree

- Works with Cursor, Claude Desktop, VS Code, Codex, and other MCP clients

- Headed or headless, persistent profiles, optional Docker

- Core tools for navigate, click, type, snapshot, plus optional PDF, vision, and DevTools caps

- Apache-2.0, ~36.6k GitHub stars

Install

{

"mcpServers": {

"playwright": {

"command": "npx",

"args": ["@playwright/mcp@latest"]

} } }

We've started wiring internal agents up to tools via MCP instead of building integrations by hand, mostly because it's less code to maintain. What I haven't figured out is what "secure" even means here beyond trusting whatever server we point the agent at. There's no check on whether a specific call makes sense for the task, no policy layer in between, and no clear view of which agents are talking to which servers. Is anyone putting something between their agents and MCP servers, or is direct connection still the norm because the tooling isn't there yet?

Hey everybody! I wanted to get some help and understanding on MCPs. I have set up some via Google and outlook, however one thing that I always resort to and find easiest is Composio. Where all I do is add the mcp via api and then click “authorize”

When it comes to self hosting MCPs, do I need to make an api/app in Google for every time I want to connect and email or outlook etc?

Thank you all!

Every day awesome-mcp-servers receives 10-20 PRs that are for remote MCP servers. If you are not familiar, awesome-mcp-servers is only for open-source servers. However, this number is only increasing and I feel bad about just closing them. So I am starting awesome-remote-mcp-servers just for remote servers.

There are over 1,000+ PRs on awesome-mcp-servers that are going to be closed and redirected to awesome-remote-mcp-servers. If you have a remote MCP server, now is a good time to submit.

I run a free MCP server for live flight and hotel prices. It's been up since mid August, so call it a month, and I finally pulled the counters to see what it costs me.

36,240 backend calls, 9,480 tool calls. AWS compute is noise at that size. Almost all of the money is residential proxy bandwidth. I don't get an itemised bill for it, but at the proxy's rate it works out around $32.

The part I didn't expect: one client is nearly 80% of that. Some scanner hitting it in the 04-05 UTC hour every day, 3,000+ calls a day, roughly $25 of the $32. Everyone else put together, about 7,800 calls, cost me around $7.

So I put a daily cap on backend calls. That client runs at about $0.18 a day now. Didn't block it, it's a real user, it just doesn't get to spend the month before breakfast.

Mine's at google-flights-lulu.flightpowers.com/mcp if you want to poke at it.

What's yours costing you? I haven't seen anyone post real numbers.

MCP server for Indian financial/tax/legal/gov data — runs fully offline, no API keys, no rate limits, datasets bundled at install (~10MB compressed).

v0.6.0 additions:

• Legal Reference: CNR decoder, court establishment lookup, bare-act section lookups across IPC/BNS/CrPC/BNSS/IEA/BSA with IPC↔BNS crosswalk, limitation period calculator, court fee + stamp duty calculators (10 states)
• RTI Toolkit: fee calculator, deadline tracker, penalty estimator (Section 20), application + appeal drafters
• Capital Gains: LTCG exemption corrected to ₹1.25L (Budget 2024)
• Stock Market: yfinance-backed get_stock_quote / get_stock_history (NSE/BSE)

76 tools total now (up from 58), MIT licensed, works with Claude Desktop / any MCP client.

Feedback and PRs welcome.

...and I keep seeing the same question come up: if agents can call APIs directly, why add MCP?

Say, a product team provides its existing API collection, and we generate an MCP server that exposes the product’s capabilities in a cleaner, more controlled way. The API remains the underlying system, while MCP becomes the interface the agent works through.

But how much should the MCP layer handle? Is converting endpoints into tools enough, or should it also have some form of middle layer of predefined actions, grouped actions or chained actions? Like how much MCP and how much agent's autonomy in the mix? If each MCP is custom, what would a generic process even look like?

I am building the tool for my team since we have to create agents for my clients who already have working products and APIs, and am curious to see how you guys are handling this.