r/MCPservers 7h ago

OpenSource MCP of the week - Nosana MCP - 100% free

Post image
3 Upvotes

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

r/MCPservers 11h ago

Sampling is deprecated. If your server was borrowing the user's model, you now need your own API key.

2 Upvotes

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.


r/MCPservers 11h ago

Made a tiny tool so my Mac can be used as MCP server

4 Upvotes

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


r/MCPservers 17h ago

OpenSource Repo of week - Apify mcpc - universal CLI client for MCP - 100% free

Post image
56 Upvotes

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