DEV Community: Ricardo Rodrigues

MCPNest — One Month. The Problem, The Solution, Every Feature Explained.

Ricardo Rodrigues — Tue, 05 May 2026 23:27:57 +0000

The Problem

The MCP ecosystem is expanding at an extraordinary pace. Anthropic, Microsoft, Google, AWS, and Cloudflare are all publishing official MCP servers. Hundreds of open source servers exist for every conceivable integration. Developers are connecting AI tools — Claude, Cursor, Windsurf — to internal databases, codebases, APIs, and filesystems.

The infrastructure for doing this exists. The governance layer does not.

Today, at most engineering teams:

Every developer runs MCP servers on their own machine
There is no central record of what servers are active
There is no audit trail of what tools were called, by whom, or when
Credentials — GitHub personal access tokens, database connection strings, API keys — are stored in JSON files on developer laptops
There is no approval process for which servers developers can use
There is no isolation — MCP servers run with the full permissions of the local user

This is the gap MCPNest fills.

The Platform

MCPNest is the governance and infrastructure platform for MCP servers. It operates across three layers: a marketplace for discovery, a gateway for control, and a hosted infrastructure layer for isolation and centralisation.

Layer 1 — Marketplace

What it is

A searchable catalogue of 7,500+ MCP servers indexed from the official Anthropic registry and GitHub. Every server has a quality score, compatibility matrix, publisher profile, and install configuration.

What problem it solves

Without a central catalogue, developers find MCP servers through GitHub searches, Reddit posts, and blog articles. There is no quality signal, no verification, no compatibility information. Teams end up with inconsistent tooling and no visibility into what is actually being used.

Features

7,500+ servers indexed with quality scores and compatibility filters
One-click install for Cursor and VS Code
Publisher profiles with verified badges
Server of the Week editorial picks
Collections and curated starter packs
Config Validator — validates syntax, endpoints, and arguments before installation
MCP Composer — build multi-server configurations and share via link
Trending servers with weekly install data

Layer 2 — Gateway

What it is

A single authenticated HTTPS endpoint per workspace. Every developer on the team points their AI client at the same Gateway URL. The Gateway authenticates the request, checks the tool allowlist, proxies to the correct upstream server, and logs the call.

What problem it solves

Without a gateway, every developer maintains their own local configuration. When a server changes, everyone updates manually. There is no central authentication, no audit, and no way to enforce which tools developers can use.

Features

Single endpoint per workspace
One URL replaces individual configurations across every developer machine. When the admin adds or removes a server, the change is immediate for the entire team.

Bearer token authentication (SHA-256)
Every request is authenticated. Tokens are stored as SHA-256 hashes with timing-safe comparison. No plain text secrets.

Per-member tokens
Each developer has their own Bearer token. This means every tool call is attributable to a specific individual, not just to the workspace. Tokens can be revoked instantly for any member without affecting the rest of the team.

Tool allowlists per member
Admins define which tools each developer can call at the protocol level. A developer with access to the GitHub MCP server can be restricted to specific tools — for example, read-only operations only. Workspace-wide enforcement toggle.

Full audit log per tool call
Every call is logged with: workspace ID, member ID, server, tool name, HTTP status, latency, timestamp, and error code where applicable. No inputs or outputs are stored — only metadata. GDPR safe by design. Logs are exportable.

Tool namespacing
Automatic conflict resolution when multiple servers expose tools with the same name. No manual configuration required.

Workspace RBAC
Three roles: Owner, Admin, Member. Only Admins can approve servers for the workspace. Separation of duties between team management and tool usage.

Layer 3 — Hosted Infrastructure

What it is

MCP servers running in isolated Docker containers on central infrastructure, managed by the MCPNest Orchestrator. Developers deploy servers from a catalogue via the workspace dashboard. The AI client connects to the Gateway, which proxies to the hosted container.

What problem it solves

Running MCP servers locally means no isolation, no central credential management, no shared infrastructure, and no visibility into what is actually running. When a developer's laptop is lost or stolen, every credential in every local config file is exposed. When a developer leaves the company, there is no clean offboarding process.

Features

12 verified servers available for one-click deploy
Filesystem, GitHub, PostgreSQL, Notion, Context7, Slack, SQLite, Brave Search, Puppeteer, Memory, Sequential Thinking, Everything. All pre-validated and running on the MCPNest Bridge image.

Container isolation
Every container runs with: cap_drop ALL (zero Linux capabilities), no-new-privileges flag, CPU and memory resource limits enforced, dedicated Docker network per workspace.

Credential management
Servers that require credentials — GitHub personal access tokens, database connection strings, Slack bot tokens, API keys — prompt for them via a modal before deploy. Credentials are encrypted and never logged. Developers never see or store them locally.

Real-time deploy console
A terminal modal streams container logs during startup. The system auto-detects RUNNING + HEALTHY state and closes automatically. No manual refresh required.

Per-instance log viewer
Every running instance has a Logs button that shows the last 50 lines of container output. Debugging without SSH access.

Terminate with cleanup
Stopping a server removes the container and cleans the database record. No orphaned containers.

MCP Bridge
A stdio-to-HTTP adapter that wraps any npx-based MCP server into an HTTP endpoint compatible with the Gateway. Enables hosting of any MCP server without modifying its source.

Security and Compliance

Infrastructure
All infrastructure is EU-based. Supabase (Frankfurt) for the database. Hetzner (Nuremberg) for the orchestrator and hosted containers. Vercel edge network for the application layer.

Token security
Bearer tokens are stored as SHA-256 hashes. Timing-safe comparison on every request. Per-member tokens enable individual audit trails and instant revocation.

Data handling
No inputs or outputs from tool calls are stored. Only metadata is logged (who, when, which tool, what status). GDPR safe by design.

Container security
cap_drop ALL removes all Linux capabilities from containers. no-new-privileges prevents privilege escalation. Resource limits prevent noisy neighbour and runaway processes. Dedicated Docker network per workspace.

Self-host
The full MCPNest stack is available for self-hosted deployment via Docker for teams that require on-premise infrastructure.

The Result

One month. 14 versions shipped. 7,500+ MCP servers indexed. Enterprise Gateway live. 12 hosted servers operational. Partnerships with Grafana, RailPush, and Context7 confirmed.

The MCP ecosystem needed a governance layer. MCPNest is it.

mcpnest.io

Hosting MCP Servers at Scale: The Orchestrator

Ricardo Rodrigues — Wed, 29 Apr 2026 20:39:35 +0000

How MCPNest deploys isolated Docker containers for MCP servers and routes tool calls intelligently across your workspace.

MCP servers have a deployment problem.

Most servers are stdio-based — they run as a subprocess via npx and communicate over stdin/stdout. That works fine on a developer's laptop. It does not work for a team.

You cannot share a stdio process across machines. You cannot health-check it remotely. You cannot restart it when it crashes without someone noticing. You cannot give five engineers access to the same instance running on one person's laptop.

The standard solution is to wrap stdio servers in an HTTP adapter and deploy them to a server. The problem: that is significant infrastructure work for every MCP server you want to use. Dockerfile, networking, health checks, restart policies, resource limits — multiply that by every server your team needs.

We built MCPNest Hosted Servers to handle all of it.

How hosted MCP servers work

When you click Deploy in your workspace Hosted tab, MCPNest:

Creates an instance record in the database (status: pending)
Sends a deploy request to the MCPNest Orchestrator service
Orchestrator pulls the verified image from our allowlist
Orchestrator starts the container with security hardening applied
Orchestrator polls health until the container responds
Updates the instance to status: running, health_status: healthy
The server automatically appears in your Gateway tools/list

Total time measured in production today: 6 seconds from click to RUNNING + HEALTHY.

The Bridge layer

Inside each hosted container runs MCPNest Bridge — a FastAPI server on port 8080 that translates between HTTP (external) and stdio JSON-RPC (internal).

Bridge handles:

MCP protocol handshake (initialize → notifications/initialized)
Managing the stdio subprocess lifecycle
Translating POST /tools/list → tools/list JSON-RPC request → response
Translating POST /tools/call → tools/call JSON-RPC request → response
Draining stderr in the background so it never blocks the main process
asyncio.Lock per request to prevent concurrent stdio corruption

The subprocess command is configurable per image via the mcp_allowed_images table. For node:20-alpine with @modelcontextprotocol/server-filesystem, the command is npx -y @modelcontextprotocol/server-filesystem /workspace.

Security model

Every container runs with these constraints — no exceptions, not configurable by the user:

Process isolation:

no-new-privileges: true — no privilege escalation
cap_drop: ALL — all Linux capabilities dropped
cap_add: [CHOWN, SETUID, SETGID] — only minimum needed

Network isolation:

Containers bind to 127.0.0.1 only — never exposed on a public interface
Traffic flows: Gateway → Orchestrator → container (all internal)

Filesystem:

/tmp mounted as tmpfs with noexec, nosuid, nodev
No host filesystem mounts

Resources:

CPU and memory caps enforced at container creation by plan profile
Small: 0.25 vCPU, 256 MB RAM
Medium: 0.5 vCPU, 512 MB RAM
Large: 1.0 vCPU, 1 GB RAM

Image allowlist:

Only MCPNest-verified images can be deployed
Images are validated against a regex pattern before pull
The DB allowlist is the primary gate; the regex is defence-in-depth

The Orchestrator

Above the containers sits the MCPNest Orchestrator — a FastAPI service that aggregates tools from all running instances in a workspace and routes tool calls to the correct container.

tools/list aggregation:

When your Gateway receives a tools/list request and orchestrator_enabled is true, it calls the Orchestrator. The Orchestrator:

Queries the database for all running instances in the workspace
Fans out POST /tools/list to each container in parallel
Collects results, detects naming conflicts
Applies namespacing: if two servers expose a tool called query, they become postgres_mcp__query and mysql_mcp__query
Caches the result for 30 seconds
Returns a unified tool list

tools/call routing:

When a tools/call arrives, the Orchestrator:

Finds the ToolInfo record for the requested tool name (from cache)
Looks up the live endpoint URL from the database
Strips the namespace prefix if present (postgres_mcp__query → query)
Forwards the call to the correct container
Logs the call to mcp_tool_calls (best-effort, non-blocking)
Returns the result

Fallback behaviour:

If the Orchestrator is unreachable, or if a workspace has no running hosted instances, the Gateway automatically falls back to direct fan-out to remote HTTP servers. No downtime. No manual intervention.

Current state

Three verified images are available today:

Server	Image	Tools
filesystem-mcp	node:20-alpine + @modelcontextprotocol/server-filesystem	read_file, write_file, list_directory
github-mcp	ghcr.io/modelcontextprotocol/servers:github	create_issue, list_prs, search_code
postgres-mcp	ghcr.io/modelcontextprotocol/servers:postgres	query, list_tables, describe_table

Plan limits: Team plan supports 3 running instances per workspace. Enterprise supports 20.

What's next

Auth headers per server (bring your own API keys — fixes degraded status on auth-required servers)
More verified images: Slack, Notion, Linear
Usage metering per instance for billing
Auto-deploy via workspace registry URL (mcpnest-registry-client npm package)

Ricardo Rodrigues — Platform Engineer @ BCP, Founder @ MCPNest
Porto, Portugal

MCPNest — The App Store for MCP Servers
mcpnest.io/workspace → Hosted tab

Enterprise MCP Governance: Gateway + Layer 2

Ricardo Rodrigues — Wed, 29 Apr 2026 20:38:30 +0000

One endpoint. Per-member tokens. Full audit trail. How MCPNest solves the team coordination problem for MCP.

When a team of engineers all use Claude with MCP servers, you have a coordination problem.

Each person runs their own npx command. Each person has their own claude_desktop_config.json. When a server URL changes, someone has to update every config. There is no audit trail. No access control. No way to know who called what tool, when, and with what arguments.

This is the current state of enterprise MCP usage in 2026. We built two layers to fix it.

Layer 1: The Gateway

MCPNest Gateway gives every workspace a single endpoint:

https://mcpnest.io/api/gw/{workspace-slug}

Behind that endpoint: all the MCP servers your team has approved. One Bearer token. All tools. Every call proxied and logged.

The Gateway speaks JSON-RPC 2.0 — the MCP standard. Claude, Cursor, and Windsurf connect to it exactly as they would to any MCP server. Your team updates one config file once. When you add or remove a server from your workspace, every connected client sees the change automatically on the next tools/list call.

Technical implementation:

Token format: mng_ prefix + 48 hex characters (192 bits of entropy)
Storage: SHA-256 hash only — the raw token is never stored in plaintext
Verification: timingSafeEqual() to prevent timing side-channel attacks
Rate limiting: 200 requests per minute per IP per workspace slug
SSE support: streaming responses for MCP servers that use Server-Sent Events
Tool prefix: configurable per server to avoid naming conflicts (github_create_issue vs gitlab_create_issue)

Layer 2: Per-Member Access Control

The workspace token is admin-level — full access to all tools. For team members, you create individual Bearer tokens with the same format but different scope.

Each member token can have an allowlist: server_slug : tool_name pairs that define exactly which tools the member can call.

How it works:

Owner creates a member token in the workspace Security tab
Owner defines allowlist rules: github-mcp:list_issues, grafana:get_dashboard
Owner enables enforcement
Member uses their token — Gateway checks allowlist on every tools/call
Blocked calls return error code -32003: Tool not allowed for this user
Every call is logged with user identity to the audit trail

The rule logic:

No rules defined: member has full access (open by default)
Rules defined + enforcement on: member can only call listed tools
Workspace admin token: always full access regardless of allowlist

What this looks like in practice

A DevOps team has three MCP servers in their workspace: GitHub, Grafana, and a custom internal deployment server.

Junior engineers get member tokens with allowlists restricted to read-only operations: github-mcp:list_issues, grafana:get_dashboard. They can query and report but not write.

Senior engineers get tokens with no allowlist restrictions. The deployment server is restricted to the team lead and the CI system.

All of this configured in the workspace UI. No code changes. No config files to distribute to each team member.

The audit log

Every action in a workspace is logged: server added, member invited, tool called, health check run. For tool calls, the log records which user (by member token identity), which server, which tool, and the response latency.

This is the audit trail your security team asks for. It exists out of the box.

Ricardo Rodrigues — Platform Engineer @ BCP, Founder @ MCPNest
Porto, Portugal

MCPNest — The App Store for MCP Servers
mcpnest.io/workspace

The MCP Discovery Problem

Ricardo Rodrigues — Wed, 29 Apr 2026 20:29:01 +0000

In November 2024, Anthropic released the Model Context Protocol —
a standard that lets AI agents call external tools. Within months,
hundreds of MCP servers appeared on GitHub. Stripe, Grafana,
Cloudflare, AWS — all publishing official servers.

The problem: there was nowhere to find them.

Developers were digging through GitHub search, Reddit threads,
and scattered READMEs to find servers that might already exist.
The official Anthropic registry had an API but no UI.
The most starred community lists had tens of thousands of
GitHub stars but weren't searchable or filterable.

This is the npm problem from 2012. A growing ecosystem
with no discovery layer.

What we built

MCPNest indexes MCP servers from the official Anthropic registry
and GitHub. 7,554 servers as of today, with quality scores,
install counts, compatibility flags per client, and one-click
install configs for Claude Desktop, Cursor, VS Code, and Windsurf.

Every server page renders the GitHub README, shows the install
config for each client, and tracks installs via a copy button
that increments a counter in Supabase.

Quality scoring

Not all MCP servers are equal. We score each server 0-100 based on:

Has a valid install config
Has a description
Is verified from the official registry
GitHub stars
Install count

The score maps to an A-F grade shown on each server card.

What this doesn't solve

Discovery is the easy part. Finding a server is step one.
The harder problems are: running it reliably, giving your team
access to it securely, and managing it at scale.

That's what we built next.

→ mcpnest.io

The MCP Discovery Problem: Why 7,500+ Servers Is Both a Victory and a Warning

Ricardo Rodrigues — Thu, 23 Apr 2026 16:38:33 +0000

The ecosystem is growing. But finding the right server is getting harder, not easier.

There is a number that gets thrown around a lot in the MCP ecosystem right now: 20000+.

That is roughly how many MCP servers exist as of April 2026. It is an impressive number. A year ago, there were a few dozen. The growth curve looks exactly like npm circa 2012–2015 — exponential, messy, and full of potential.

But there is a problem nobody is talking about loudly enough.

The discovery problem did not get smaller when the ecosystem grew. It got bigger.

From "does it exist?" to "which one doesn't break in production?"

In early 2025, the question developers asked was simple: is there an MCP server for Postgres? For Slack? For GitHub?

The answer was usually no, or "sort of, check this GitHub repo."

By April 2026, the answer to almost every "is there an MCP for X?" question is yes — often with four to eight options. The new question is harder: which one is maintained? Which one has an install config that actually works? Which one is still actively developed?

A developer covering the MCP ecosystem at miaoquai.com framed this shift better than I have seen anywhere else — paraphrasing from the original Chinese: users are no longer asking whether an MCP server exists for something. They are asking which one is actually good. That move, from "does it exist?" to "which one is trustworthy?", is how you know an ecosystem is maturing.

This is the shift from scarcity to noise. And it is the hardest phase of any ecosystem to navigate.

The signal problem

When developers browse the 7,561 servers indexed at MCPNest, the most common question is not "is there a server for X?" — it is "which of these four options for X should I actually use?"

The default answer most people fall back on is GitHub stars. Stars are visible, comparable, and familiar. The problem is that stars measure historical interest. They tell you how many people were excited about a server at some point in the past. They tell you very little about whether it will work today.

A server can accumulate thousands of stars and then go unmaintained. The stars stay. The maintenance does not.

What quality actually means for an MCP server

We built a Quality Score (A–F) for every server in the MCPNest registry. Not because scores are fun — but because without a better signal, developers keep defaulting to star counts.

The factors we look at:

Maintenance velocity. When was the last commit? A server updated two weeks ago is categorically different from one updated six months ago, even if the code looks identical.

Config completeness. Does the server have a working install config for Claude Desktop, Cursor, or VS Code? A server without a valid install config is not really usable by most developers, regardless of what the README says.

Verification status. Is it listed in the official Anthropic registry? Not a quality guarantee, but a meaningful baseline signal.

Documentation depth. Does the README explain what the server actually does, what tools it exposes, and what credentials it needs?

The principle is simple: a well-maintained server with 300 stars should score higher than an abandoned one with 3,000. That is what we are trying to make visible.

The npm parallel

npm crossed 100,000 packages in 2015. The JavaScript community went through a long reckoning about package quality, maintenance, and trust — left-pad, node_modules bloat, abandoned dependencies pulling production apps down with them.

The MCP ecosystem is smaller and moving faster. A similar reckoning will happen. The question is whether the tooling to handle it gets built proactively or reactively.

What comes next

Quality scoring is a start, but it is a static snapshot. What matters more is dynamic health — knowing when a server you depend on stops being maintained, or when a previously low-scoring server improves significantly.

The goal is not to gatekeep the ecosystem. Every server deserves to be discoverable. The goal is to give developers the context to make informed decisions quickly, so they spend less time debugging abandoned configs and more time building.

7,561 servers indexed is a milestone. But the milestone that actually matters is: how many of those are good, maintained, and ready to use today?

That is the number we are working on making transparent.

MCPNest (mcpnest.io) is a marketplace for MCP servers with Quality Scores, one-click install for Claude, Cursor, Windsurf and VS Code, and an enterprise Gateway for teams.

MCPNest Gateway — One URL to Rule All Your MCP Servers

Ricardo Rodrigues — Wed, 22 Apr 2026 13:35:55 +0000

MCPNest v1.11 | April 2026

The MCP ecosystem has a governance problem.

Developers are installing MCP servers directly into Claude Desktop and Cursor — GitHub integrations, database connectors, web scrapers, API wrappers. The tools are good. The problem is that nobody in IT knows which ones are running, who installed them, or what they're doing.

This is the problem the MCPNest Gateway solves.

The Problem With How Teams Use MCP Today

When a developer wants to add an MCP server to their Claude Desktop setup, they edit a JSON file:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_..." }
    }
  }
}

This works fine for one developer. It falls apart for a team.

There is no central list of which servers are approved. No versioning — if a server updates and breaks something, there is no rollback. No audit trail — if Claude connects to an external system and something goes wrong, there is no record of what happened. And no access control — any developer can add any server without approval.

For individual developers, none of this matters. For a team of 20 at a company that cares about security, it is a governance gap.

What the Gateway Does

The MCPNest Gateway gives each Enterprise workspace a single authenticated endpoint:

https://mcpnest.io/api/gw/{workspace-slug}
Authorization: Bearer mng_...

Instead of each developer maintaining their own JSON config with multiple servers, they point Claude Desktop or Cursor at this one URL. The Gateway handles everything else.

tools/list — When Claude asks what tools are available, the Gateway calls tools/list on every server approved in the workspace, aggregates the results, and returns a unified list. From Claude's perspective, it is talking to one server. Behind the scenes, it might be five.

tools/call — When Claude calls a tool, the Gateway identifies which server owns that tool and proxies the request. The developer does not need to configure anything. The routing is automatic.

Logging — Every tool call is logged at the protocol level: which tool was called, on which server, with what status code, and how long it took. No input or output content is stored — only metadata. GDPR-safe by design.

The Architecture

The Gateway is built on three files.

auth.ts handles token verification. Bearer tokens are stored as SHA-256 hashes — never in plaintext. Comparison uses timingSafeEqual to prevent timing attacks. Tokens use a mng_ prefix so they are immediately recognisable in logs and distinguishable from other API tokens.

logging.ts handles fire-and-forget writes to mcp_tool_calls. If the table does not exist or the write fails, the proxy continues — logging never blocks a tool call.

route.ts handles the actual proxying. It resolves the workspace, verifies the token, parses the JSON-RPC body, fetches tools from each upstream server, and routes calls to the correct endpoint. It supports both JSON and SSE transport — auto-detecting from the response content-type header — because different MCP servers use different transports.

The database schema is straightforward:

gateway_workspaces — one row per workspace, with the token hash and plan
gateway_workspace_servers — which servers each workspace exposes, with position ordering and optional tool prefix to avoid name collisions
mcp_tool_calls — append-only log of every tool call, retained for 90 days

What Gets Logged

Each row in mcp_tool_calls contains:

workspace_id — which workspace made the call
server_slug — which upstream server handled it
tool_name — which tool was called
status — HTTP-style status code (200 for success, 4xx for client errors, 5xx for upstream errors)
latency_ms — how long the round trip took
created_at — timestamp

Nothing from the input parameters or output content is stored. The log answers "what happened" without storing "what was said."

A Real Test

After deploying, I tested with a workspace containing the Context7 MCP server (documentation lookup) at https://mcp.context7.com/mcp.

curl -s -X POST https://mcpnest.io/api/gw/bcp-test \
  -H "Authorization: Bearer mng_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "resolve-library-id", "description": "..." },
      { "name": "query-docs", "description": "..." }
    ]
  }
}

Two tools returned, proxied through the Gateway, logged in mcp_tool_calls. Latency around 1000ms — the Gateway adds minimal overhead on top of the upstream server response time.

The Supabase log confirmed 5 calls, all status 200, latencies between 821ms and 1440ms.

What This Means for Enterprise Teams

The question most IT teams ask when developers start using AI tools is: "What is Claude actually connecting to?"

Without the Gateway, the answer is "we don't know." Each developer has their own config. Servers come and go. There is no central record.

With the Gateway, the answer is: every tool call is in mcp_tool_calls. IT controls which servers are in the workspace. Developers cannot add servers without admin approval. Every action has a timestamp and an owner.

It is the same principle as an API gateway like Kong or AWS API Gateway, applied to the MCP protocol.

Current Limitations

The Gateway v0 works with MCP servers that have a remote HTTP endpoint. Local servers — those that run via npx or node on the developer's machine — cannot be proxied because they have no public endpoint to route to. This covers a significant portion of the MCP ecosystem today.

Servers that require authentication (like RailPush, which needs a Bearer token) need their credentials configured in the workspace config_override. There is no UI for this yet — it requires a direct database insert.

There is also no workspace creation UI yet. Workspaces are created via SQL. This is the next thing to build.

What Comes Next

The immediate next step is a workspace creation UI — a page where Enterprise users can create a workspace, add servers, generate a Bearer token, and copy the Gateway URL. Right now all of this requires direct database access.

After that: token rotation UI, per-server health status in the Gateway response, and rate limiting per workspace.

The longer-term goal is making the Gateway the standard way teams distribute MCP server access — the same way Artifactory or a private npm registry distributes packages, but for MCP servers.

MCPNest is a marketplace and governance layer for MCP servers. 7,561+ servers indexed. Gateway live since April 20, 2026. Free to use at mcpnest.io — Enterprise for teams.

Tags: MCP, Model Context Protocol, TypeScript, Claude, Enterprise AI, API Gateway, Developer Tools

The MCP Generator — Scaffold a Working MCP Server in 60 Seconds With Plain English

Ricardo Rodrigues — Mon, 20 Apr 2026 11:00:11 +0000

Published on MCPNest Blog | April 2026

Most developers who want a custom MCP server don't build one.

Not because they can't. Because starting is hard.

Where do you begin? Which SDK version? What's the right file structure? How do you register tools correctly? How do you handle errors? What does claude_desktop_config.json need to say to load the server?

These questions cost time. A developer unfamiliar with the MCP SDK typically spends 2-4 hours on setup before writing a single line of actual tool logic. For a solo developer or a platform engineer who already has a full day job, that's the entire Sunday afternoon gone before anything useful runs.

The barrier to publishing an MCP server is high. The MCP Generator lowers it.

What It Does

The MCP Generator takes a plain English description — up to 500 characters — and returns a complete MCP server scaffold in TypeScript. What would take 2-4 hours reading SDK documentation takes 30 seconds.

You describe what you want. The Generator builds the structure.

Input examples:

"A server that fetches real-time weather for any city"
"An MCP server that queries a Postgres database and lists tables"
"A server that reads and writes files in a local directory"

Output: A JSON object with four fields:

{
  "name": "weather-mcp-server",
  "description": "Fetches real-time weather data for any city using the OpenWeather API",
  "code": "// Complete TypeScript MCP server code...",
  "install": "{ \"mcpServers\": { \"weather-mcp-server\": { \"command\": \"npx\", \"args\": [\"-y\", \"weather-mcp-server\"] } } }"
}

The code field is a complete TypeScript file — tool registration, request handlers, error handling, and the correct SDK boilerplate. The install field is the config snippet ready to paste into claude_desktop_config.json.

TypeScript always. Not JavaScript. The MCP SDK is TypeScript-first and the Generator follows that convention.

How It Works Under the Hood

The Generator calls the Anthropic API directly — /v1/messages with Claude Haiku. A specialised system prompt instructs the model to generate MCP servers that follow the correct SDK conventions, register tools with the right schema structure, and output the result as valid JSON.

This is worth explaining because it matters for what the Generator is and isn't.

It is not a code database. It is not a template engine. It is Claude, with a very specific prompt, generating TypeScript code for your exact use case on demand.

That means the output is tailored to your description. It also means the quality of what you get depends on how clearly you describe what you want. A precise description produces a precise scaffold. A vague one produces a generic one.

The Problem It Solves

Building an MCP server from scratch has a steep entry cost even for experienced developers. The official MCP TypeScript SDK is well-documented, but documentation takes time to read. And most of what you need to set up — the server initialisation, the tool list handler, the tool call handler, the transport setup — is identical across every server.

The parts that are unique to your use case are the tool implementations themselves: the actual logic that calls your API, queries your database, or reads your filesystem. Everything else is boilerplate.

The Generator handles the boilerplate. You write the logic.

It's the same principle as create-react-app or npm init — not a replacement for knowing how to code, but a fast path to the starting line.

What You Get

When you run the Generator with a description like "a server that connects to a Postgres database with tools to query tables, list schemas, and run SELECT statements", the output includes:

Correct tool registration — each tool defined with its name, description, and JSON Schema for input parameters. Missing or incorrect schemas are the most common cause of MCP servers not loading.

Both required request handlers — ListToolsRequestSchema and CallToolRequestSchema, correctly wired up. Forgetting either breaks the server entirely.

Error handling for unknown tools — a catch that throws a meaningful error instead of hanging silently.

Environment variable placeholders — if your server needs an API key or connection string, the Generator uses process.env.YOUR_VAR with a clear comment.

Ready-to-use install config — the exact JSON snippet for claude_desktop_config.json, with the correct server name and command.

Limitations

The Generator is honest about what it is.

It produces a scaffold, not a finished server. The tool implementations — the actual calls to your API, the database queries, the file reads — are placeholders that you replace with your own logic. The Generator gives you the correct structure so you don't have to figure that out from documentation. The business logic is yours.

It requires sign-in to use. This is to prevent abuse of the underlying API call.

The output is always TypeScript. If you need JavaScript, you can transpile it, but the Generator won't produce JS directly.

And because it uses a language model to generate code, edge cases or unusual patterns may not always produce exactly what you expect. Treat the output as a strong starting point, not as production-ready code that needs no review.

Try It

The MCP Generator is at mcpnest.io/tools.

Sign in, describe your server, and get your scaffold. Add your logic, push to GitHub, and if you want it in the MCPNest registry, submit it at mcpnest.io/publish.

If you build something with it and the listing doesn't exist yet, submitting it helps the registry. Every new server makes it more useful for everyone looking for tools.

And if the Generator produces something wrong, or if there's a pattern it doesn't handle well, tell me: malasartes@mcpnest.io. The prompt gets better every time I learn about a gap.

Ricardo Rodrigues is the founder of MCPNest and a Platform Engineer at BCP in Porto, Portugal. MCPNest is the marketplace and governance layer for MCP servers — 7,561+ servers indexed, with Enterprise workspaces and a Gateway launching June 2026.

Tags: MCP, Model Context Protocol, TypeScript, Claude, AI Tools, Developer Tools, MCP Generator

How I Built the MCP Composer — And Why It Was the Most Requested Feature at MCPNest

Ricardo Rodrigues — Sun, 19 Apr 2026 00:20:51 +0000

I launched MCPNest on April 4th, 2026. Within 48 hours, the most common question in my DMs wasn't "how do I find servers" or "why isn't my server listed."

It was: "How do I install multiple servers at once?"

That question became the MCP Composer.

The Problem No One Was Talking About

When people discover MCP servers, they don't install one. They install five. A developer setting up Claude for serious work typically wants:

A GitHub server (read repos, create issues, review PRs)
A database server (query Postgres or SQLite)
A file system server (read and write local files)
A documentation server (pull live docs from any library)
A search server (web or internal search)

That's five separate servers. Five separate JSON blocks. Five separate edits to claude_desktop_config.json.

The official config format looks like this:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "..." }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
    }
  }
}

Writing this by hand is error-prone. A missing comma breaks everything. A wrong argument crashes Claude on startup. And when something goes wrong, the error messages are cryptic.

I watched people spend 30-45 minutes on something that should take 30 seconds. Platform engineers who manage CI/CD pipelines every day were struggling with a JSON config file.

That was the moment I decided to build the Composer.

Where the Idea Came From

I'm a Platform Engineer at a bank. During the day, I manage infrastructure tooling — the kind of work where you spend a lot of time thinking about developer experience. Why does it take a new engineer three days to set up their local environment? Why are there seventeen steps in the onboarding doc when there should be one?

When I started building MCPNest, I knew the discovery problem was obvious — everyone could see there was no central registry for MCP servers. But the installation problem was the hidden one.

The gap I saw was this: even if you found the right servers on MCPNest, you still had to manually construct the JSON config, copy it into the right file on your machine, restart Claude, and hope nothing broke.

That's too many steps. Too much friction between "I want this tool" and "this tool is running."

The Composer was my answer to that friction.

What the MCP Composer Does

The MCP Composer (available at mcpnest.io/compose) lets you build a complete multi-server MCP configuration in under 30 seconds — visually, without touching JSON.

Here's how it works:

Step 1: Search and add servers
You search the MCPNest catalogue of 7,561+ servers and add any combination to your config. Each server is shown with its compatibility, required arguments, and any environment variables it needs.

Step 2: Configure each server
For servers that need arguments (like a database URL, a file path, or an API key), the Composer shows you exactly what's needed. You fill in the values once. No looking up documentation.

Step 3: Choose your client
Select your target: Claude Desktop, Cursor, Windsurf, or VS Code. The Composer generates the exact config format for each client — they're slightly different, and getting the format wrong means nothing works.

Step 4: Copy or download
The complete config JSON is ready to paste. Or you can use Bundle Sharing to generate a link that anyone can use to replicate your exact setup in one click.

The Six Problems the Composer Solves

1. JSON syntax errors
The single biggest cause of "why isn't my MCP server working" is a malformed JSON config. A trailing comma, a missing bracket, wrong quote type — any of these breaks the entire file. The Composer generates syntactically valid JSON every time.

2. Wrong config format per client
Claude Desktop, Cursor, Windsurf, and VS Code each have slightly different config formats. Claude Desktop uses claude_desktop_config.json in one location on Mac, another on Windows. Cursor has its own format. The Composer knows all of them and generates the right one.

3. Missing required arguments
Many MCP servers require arguments — a database connection string, a file path, an API token. When you install manually, you often miss these and the server fails silently. The Composer shows every required argument upfront.

4. Multi-server conflicts
When you have ten servers in your config, one bad entry can prevent all of them from loading. The Composer validates the full config before you copy it, catching conflicts before they cause problems.

5. Knowledge barrier
Not everyone knows what npx -y does or why some servers use command: "node" and others use command: "npx". The Composer abstracts this — you see server names, not command syntax.

6. Sharing and replication
If you've built a good MCP stack, sharing it with your team means sending a JSON blob in Slack and hoping they paste it correctly. With Bundle Sharing, you share one link. They click it, they get your full config.

How to Use the MCP Composer

Go to mcpnest.io/compose. Here's a real example — building a developer stack from scratch:

Adding GitHub:
Search for "github", select github-mcp-server (official, 28,700+ stars). The Composer shows you need one environment variable: GITHUB_PERSONAL_ACCESS_TOKEN. Enter your token. Done.

Adding Postgres:
Search for "postgres", select the official server. The Composer asks for a connection string: postgresql://username:password@localhost:5432/mydb. Enter it. Done.

Adding Context7:
Search for "context7", add it. No configuration needed — it works immediately with no arguments. The Composer handles the command automatically.

Generating the config:
Switch to "Claude Desktop" tab. Click "Copy config". Paste into claude_desktop_config.json. Restart Claude.

Total time: under two minutes for a three-server setup that would have taken 20-30 minutes manually.

Bundle Sharing: The Feature Within the Feature

After I shipped the Composer, something unexpected happened. People started using it not just for themselves — but to share their stacks with others.

A developer would compose their perfect setup, generate a bundle link, and post it on Reddit or Twitter: "Here's my MCP stack for backend development." Others would click the link, get the full config ready to paste, and be up and running in seconds.

This became Bundle Sharing — a dedicated feature built on top of the Composer. You can browse shared bundles at mcpnest.io/bundle-sharing, or create your own with the "Share bundle" button in the Composer.

For teams, this is particularly powerful. A platform engineer sets up the approved MCP stack for their company, generates a bundle link, and shares it in the engineering onboarding doc. Every new hire gets the same setup, correctly configured, in one click.

What's Next for the Composer

The Composer currently handles local MCP servers — the ones you run with npx or node on your machine.

The next evolution is the Gateway, launching June 16, 2026. Instead of each developer running servers locally with their own config, the Gateway gives every workspace a single authenticated URL. One URL replaces the entire config. One click deploys approved servers to your whole team.

The Composer was the first step in making MCP servers accessible. The Gateway is the step that makes them governable.

Try It

The MCP Composer is free, requires no account, and works with Claude Desktop, Cursor, Windsurf, and VS Code.

mcpnest.io/compose

If you have a stack you love, generate a bundle and share it. I'd love to see what people are building.

And if something doesn't work — if a server config is wrong, if a client format is off, if the Composer is missing a server you need — email me: malasartes@mcpnest.io

Tags: MCP, Model Context Protocol, Claude Desktop, Cursor, AI Tools, Developer Tools, MCP Composer

MCPNest Enterprise: The Private MCP Registry Your Team Has Been Missing

Ricardo Rodrigues — Thu, 16 Apr 2026 16:55:42 +0000

If you're using Claude, Cursor, or Windsurf with MCP servers, you've probably hit this wall: you find a great server, configure it locally, and then spend the next hour explaining to your colleagues how to do the same. JSON configs in Slack messages. "Did you add the right environment variable?" Version mismatches between machines. Someone installs the wrong server. IT has no idea what AI tools are running on company infrastructure.

MCPNest Enterprise solves this.

What Is MCPNest Enterprise?

MCPNest (mcpnest.io) is the marketplace for MCP servers — 7,561+ indexed, one-click install for Claude Desktop, Cursor, and Windsurf. Enterprise is the layer built on top of it for teams that need to manage MCP servers at scale, with governance, auditability, and control.

Think of it as the npm private registry for your team's MCP servers. Or Docker Hub with access control. The same idea: your team gets a curated, approved set of tools — without anyone editing JSON files manually.

The Core: Private Workspace

Every Enterprise workspace is a private environment that only your team can access. You create it, invite your colleagues, and from that point forward you have a single source of truth for which MCP servers your team uses.

No more "which version are you on?" No more "where's the config file for that?"

What lives inside a workspace:

Private server registry — add any MCP server (remote endpoint or local config) to your workspace. It stays internal and is never exposed publicly.
One registry URL — a single authenticated endpoint that your team points their Claude Desktop, Cursor, or Windsurf config to. One change on the server side, everyone gets it.
Version control per server — publish versions (v1.0.0, v1.1.0), track what changed, roll back if something breaks.
Audit log — every action is logged: who added a server, who published a version, who invited a member, when.
Health monitoring — the workspace runs health checks on every remote server. You know immediately when something is degraded or down, before your team starts filing bug reports.

Team Management

Enterprise workspaces have three roles: Owner, Admin, and Member.

The owner has full control. Admins can add servers, publish versions, and invite members. Members can install and use what's been approved for them — nothing more.

This matters for enterprise adoption. The platform engineer sets up the workspace and curates the approved servers. Developers self-serve within those guardrails. IT can see the audit log. Everyone wins.

Inviting a colleague is one email address. They get access immediately if they have an MCPNest account. Remove them just as easily — access is revoked instantly.

The Registry Endpoint

This is the most important technical feature.

Every workspace gets a unique authenticated URL:

https://mcpnest.io/api/registry/YOUR_WORKSPACE_TOKEN

Your team adds this to their Claude Desktop config once:

{
  "mcpServers": {
    "mcpnest-registry": {
      "command": "npx",
      "args": ["mcpnest-registry-client", "--url", "https://mcpnest.io/api/registry/YOUR_TOKEN"]
    }
  }
}

From that point forward, every server you add to the workspace is automatically available to everyone on the team. No individual config changes. No manual distribution. The registry is the single source of truth, and it updates centrally.

Version Control

MCP servers evolve. Endpoints change. Configs need updating. Without version control, you're back to the Slack message problem — "hey everyone, update your config to use the new endpoint."

With MCPNest Enterprise, you publish a new version to the workspace. Set the version number, write a changelog entry, update the install config if needed. Everyone on the team gets the update automatically through the registry endpoint.

If the new version breaks something, you can see exactly what changed and when. The audit log has the full history.

Health Monitoring

Every workspace has a live health dashboard showing which servers are Healthy, Degraded, or Down.

Health checks run automatically every 60 minutes against every remote endpoint in your workspace. If a server goes degraded — timeout, authentication failure, unexpected response — you see it in the dashboard immediately. Before your developers start wondering why Claude isn't responding to tool calls.

You can also trigger a manual health check at any time.

Audit Log

Every action in a workspace is logged with the user, the action type, the timestamp, and any relevant details.

Workspace created
Server added
Version published
Member invited
Member removed
Health check run

This isn't just for debugging. It's for compliance. Enterprise teams need to know what AI tools are running on their infrastructure and who approved them. The audit log gives you that.

The Customisable Dashboard

The workspace overview is designed to show what matters to your team, not a generic set of metrics.

You get five KPI cards — Servers, Members, Installs, Events, Remote — and a grid of widgets you can toggle on and off: the server list, health overview, activity feed, registry endpoint, team members, and quick actions to MCPNest tools.

Your workspace, your layout. Preferences are saved per workspace.

The dashboard also supports light and dark mode — persisted in your browser across all workspace pages.

What's Coming

Enterprise is the foundation. What's being built on top of it:

MCP Gateway (launching June 2026) — one URL per workspace, with routing, authentication, and logging for every tool call. The difference between the current registry and the Gateway is observability: with the Gateway, you see every tool invocation, every parameter, every response. Full auditability at the protocol level.

Invite emails via Resend — when you invite a team member, they receive a proper onboarding email.

GitHub sync — link a server to a GitHub repository and the workspace automatically picks up new releases.

Why This Matters

MCP is the standard that's emerging for how AI agents connect to tools. Every serious AI-powered development team will eventually need to manage a set of MCP servers — which ones are approved, which versions are running, who has access to what.

Right now, most teams are doing this manually. JSON configs, documentation wikis, Slack messages. That doesn't scale past five people.

MCPNest Enterprise is the infrastructure layer that makes MCP adoption manageable at team scale. The same way npm private registries made Node.js dependency management manageable for enterprise teams.

Get Started

MCPNest Enterprise is available at mcpnest.io

Create a workspace, add your first server, and share the registry URL with your team.

If you're building a team AI tooling stack and want to talk, reach out at malasartes@mcpnest.io.

Ricardo Rodrigues is the founder of MCPNest and a Platform Engineer at BCP. MCPNest is built in Porto, Portugal.

MCPNest - I built an MCP server marketplace in 7 days.

Ricardo Rodrigues — Tue, 14 Apr 2026 22:46:59 +0000

I'm a Platform Engineer at a bank in Porto, Portugal.

On 3 of April I had an idea. Today it's a live product with 7,554 servers, partnerships with Railpush, Grafana and other coming.

Here's the full story.

The problem

The MCP (Model Context Protocol) ecosystem was exploding. Every week a new server appeared on GitHub, got 500 stars, and disappeared into the void.

Developers wanting to extend Claude, Cursor, or Windsurf had to dig through GitHub repos, Reddit posts, and scattered READMEs.

There was no discovery layer. No App Store for MCP.

The plan

Build the npm registry for MCP servers. Fast.

The criteria: buildable in days, real market timing.
MCPNest won.

What I built

Starting from zero, in two weeks:

Discovery
7,554+ MCP servers indexed from the official Anthropic registry and GitHub. Search by name, category, client compatibility. Quality Score A–F. Security badges — Verified, No Auth, Local Process, Remote.

Install
One-click install configs for Claude Desktop, Cursor, Windsurf, and VS Code. Copy one JSON snippet and you're done.

Bundle Sharing
Create a named bundle of multiple MCP servers and share it as a single link. Someone clicks it, gets the combined config for all servers at once. Useful for teams that want to share a standard MCP setup without going through the full Enterprise tier.

MCP Composer
Build your full multi-server config visually. Select servers, fill in your keys, copy once.

MCP Generator ← the one I'm most proud of
Describe what you want in plain english. Claude writes the full TypeScript MCP server — tool schema, error handling, stdio transport — plus the install config. From idea to published server in under a minute.

Collections
Curated starter packs. Install a full stack in one config.

Enterprise Workspace
This is the one I'm betting on long term.

A private MCP registry for teams. The idea came from a conversation with an AI leader at a large enterprise who said: "IT and security won't let us install third-party MCP. We just need the recipe to build it ourselves."
What's live:

Private registry with a single URL — your whole team points their config to it
Version control — publish v1.1 and every team member gets the updated config immediately, no manual updates
GitHub sync — link a repo and pull the latest version with one click
Health monitoring — hourly cron checks all remote server endpoints, updates UP/DOWN status automatically
Audit log — every action tracked: who added what, when, from where
Team management — owner, admin, and member roles
Invite by email — add team members who already have an MCPNest account

The GTM strategy is bottom-up, like Slack. Individual enterprise employees start using it via open source. They build their own configs, use the Composer, share bundles with colleagues. When IT notices, the Enterprise tier gives them the governance layer they need — SSO, audit logs, private registry, version control.

Credential Manager
Store API keys per server. The biggest friction point in MCP tooling — solved.

Publisher Analytics
30-day install charts, client breakdown, weekly performance. Know what's working.

Reviews + Ratings
The first MCP marketplace with community reviews.

The stack

Next.js 16 with Turbopack
Supabase (database + auth)
Vercel (hosting)
Stripe (payments)
FastAPI crawler on Railway
Built almost entirely in Claude sessions

The honest part

Features are the easy part. Distribution is hard.

650 visitors a week is not enough. The product is good. The challenge now is getting people to find it.

If you're building with MCP — mcpnest.io

If you publish MCP servers — list yours

Solo founder. Platform engineer by day. Building as fast as I can.