DEV Community: Ricardo Rodrigues

The Day Your AI Agent Has the Keys to Everything

Ricardo Rodrigues — Sun, 24 May 2026 13:06:47 +0000

There's a moment coming in your company, if it hasn't arrived already.

A developer wires up an AI agent — Claude, Cursor, whatever your team uses — to a Model Context Protocol server. Suddenly the agent can query your production database, read your private repos, hit internal APIs, trigger deployments. Not suggest doing those things. Do them. Autonomously, in response to natural language, often without a human approving each action.

On a laptop, that's a productivity miracle. In production, it's a question nobody in the room can answer: who is allowed to do what, and how would we ever know what happened?

That question is the one this piece is about. Because the answer, for most companies adopting MCP today, is: we have no idea.

The pattern we've seen before

If you've been in infrastructure long enough, this rhymes with something.

A decade ago, microservices arrived the same way. Teams split monoliths apart, called the pieces "services," and shipped. The architecture was exciting; the governance was an afterthought. We spent the next five years retrofitting service meshes, API gateways, identity, and observability onto systems that were never designed to be governed. The cleanup cost more than the migration.

MCP is at the exact same stage microservices were in 2014 — explosive adoption, no governance layer, and a collective decision to worry about security later.

"Later" has a way of arriving as an incident.

The gap, stated plainly

Here is what MCP adoption actually looks like inside most teams right now:

Every developer installs their own MCP servers, with their own credentials, on their own machine. Security has no approved list and no visibility into what's connected. Many of those servers run as local processes — meaning they can't be centrally monitored, shared, revoked, or audited. And when an agent does something — queries a customer table, posts to a channel, runs a command — there is no record of who initiated it, through which identity, or whether it should have been allowed.

This isn't hypothetical. Security researchers recently found roughly 1,800 MCP servers exposed to the public internet. Of the sample they analyzed, every single one accepted unauthenticated requests. Some of those servers connect directly to internal systems that would otherwise never be reachable from outside.

Read that again: tools that can act on internal infrastructure, reachable by anyone, authenticating no one.

Why this is worse than a normal security gap

A normal vulnerability is a door someone might pick. This is different, and worse, in two specific ways.

First, the agent is unpredictable by design. A traditional application does what it was coded to do. An AI agent does what it's persuaded to do. If a developer points an agent at an untrusted web page or an unvetted codebase, an attacker can embed instructions in that content — and the agent, trying to be helpful, may call a real tool with real credentials. The infrastructure did nothing wrong. The agent was simply talked into it. Your firewall has no concept of "the model was tricked."

Second, there's no chain of custody. When the incident review happens — and at scale, it always eventually happens — the question will be: which agent, acting for which person, called which tool, against which system, and was that permitted? If your MCP setup is a pile of local configs, you cannot answer that. Not because you didn't log enough. Because the activity never passed through anywhere that could log it.

This is the part that turns a quiet adoption decision into a board-level risk: by the time you need the audit trail, it's too late to have started keeping one.

What governing this actually requires

Strip away the noise and the requirements are not exotic. They're the same disciplines identity providers brought to applications fifteen years ago — applied, now, to tool calls made by AI.

You need a single point every tool call passes through, instead of dozens of direct, ungoverned connections. You need per-person identity, so every action is attributable and individually revocable — not a shared token that gives everyone the same keys. You need tool-level permissions, so a support engineer's agent can read a ticket but not delete a database. And you need an audit trail of every call — who, what, when, outcome — that exists by default, not as something you scramble to bolt on after the first scare.

Notice what governs this can't be the individual server, and can't be the client. A local server can harden itself but can't prove custody across a team. The client can't reason about what other members are doing. The governance has to live at the layer all the traffic passes through. That's not a feature you add to MCP. It's a layer you put in front of it.

Where this goes

The companies that get this right won't be the ones with the most AI agents. They'll be the ones who can answer, on any given Tuesday, exactly what their agents did and whether it was allowed. That capability is about to separate the teams that scale AI safely from the ones that quietly accumulate risk until it surfaces.

This is the layer we build at mcpnest.io — a governed gateway for MCP, with per-member access, tool-level permissions, hosted infrastructure, and a protocol-level audit log that stores metadata, never payloads, so it's EU-resident and clean by construction. One endpoint your team connects through. Everything attributable. Everything revocable. Everything recorded.

If you're adopting MCP and the questions in this piece made you slightly uncomfortable, that discomfort is the signal. You can scan your own MCP configuration for these exact risks, free and entirely in your browser, at mcpnest.io/scan — nothing leaves your machine.

The microservices generation learned the cost of governing too late. The MCP generation doesn't have to.

Why Enterprises Will Struggle With MCP — And What to Do About It

Ricardo Rodrigues — Wed, 20 May 2026 14:35:16 +0000

What Enterprise IT Asks First

When any new technology enters an enterprise, four questions must be answered before broad deployment:

Who has access to what?
What happened, and when?
How do we remove access when someone leaves?
Can we prove compliance to an auditor?

For MCP today, in a default setup, the honest answers are: everyone has access to everything, we do not know what happened, we cannot remove access without breaking the whole team, and no we cannot prove compliance.

This is not a reason to avoid MCP. It is a reason to build the governance layer before the rollout, not after.

The Three Phases Every Enterprise Goes Through

Phase 1 — Exploration
A few developers install MCP servers individually. Cursor with GitHub integration. Claude Desktop with a database connector. Productivity improves visibly. Word spreads internally.

Phase 2 — Team Adoption
Teams start sharing configs. Someone creates a recommended MCP stack document. A workspace token gets shared in Slack. Now the entire team is using the same token with the same access to the same tools. Nobody is logging anything. Security has no visibility.

Phase 3 — The Incident
Something unexpected happens. A production query runs at an unexpected time. A file gets modified that should not have been. An internal API gets called by an agent nobody authorised. Now the question is: "what happened, and who did it?" Nobody can answer it.

This is the moment governance becomes urgent. The problem is that retrofitting governance into an existing MCP deployment is significantly harder than building it correctly from the start — because you have no historical data, no baseline, and no audit trail from before the governance layer existed.

The Seven Capabilities Enterprise MCP Requires

1. Centralised endpoint
One authenticated URL per team. Not dozens of individual JSON configs across dozens of developer machines. A single point of control, logging, and revocation.

2. Per-member identity
Every tool call attributable to a specific person. Not "the workspace called something." Individual tokens per member, so the audit trail captures who did what.

3. Tool-level access control
The ability to say "Alice can use these tools, Bob can use those." Enforced at the protocol level. The principle of least privilege applied to AI tooling.

4. Isolated server deployment
MCP servers running in defined, auditable environments — not on developer laptops. Containers with clean lifecycle management: deployable, monitorable, and terminatable centrally.

5. Quality and trust signals
A trust signal per server that goes beyond GitHub stars. Maintenance velocity, last commit date, publisher verification, config completeness — visible before installation.

6. Instant revocation
When someone leaves the team, their access gone in seconds. Without rotating the workspace token. Without reconfiguring every AI client on the team. Individual member revocation with no blast radius.

7. Protocol-level audit log
A record of every tool call — who called it, which tool, which server, when, and whether it succeeded. Not application-level logging. Protocol-level logging that captures everything that flows through the gateway.

None of these are optional for enterprise. All of them are absent from a default MCP setup.

The Retrofit Problem

The most expensive version of this problem is the one teams build toward without realising it.

A team that deploys MCP without governance for six months has six months of tool calls with no attribution, no audit trail, and no access history. When an auditor asks "what did your AI agents have access to between January and June?", the answer is "we do not know."

That answer is not acceptable in regulated industries. It is barely acceptable in any enterprise context where AI agents have access to production systems.

The teams that establish governance now will have a clean audit trail from the first tool call. The teams that wait will be unable to reconstruct the past.

The Window Is Now

MCP adoption in enterprise is in Phase 1 and early Phase 2 for most organisations. The exploration is happening. The team adoption is beginning.

The governance layer needs to arrive before Phase 3.

Building it after an incident is possible. It is just significantly more expensive — in time, in credibility, and in the irreversible absence of historical audit data.

MCPNest is the enterprise governance layer for MCP servers — Gateway, per-member access control, hosted infrastructure, and audit logging for AI engineering teams.

mcpnest.io

The MCP Security Gap No One Is Talking About

Ricardo Rodrigues — Sun, 17 May 2026 17:11:34 +0000

The MCP ecosystem is growing fast. Thousands of servers, dozens of clients, and teams across the industry moving from personal experimentation to production deployments. But there is a security architecture problem baked into how most teams are using MCP today — and most of them do not know it yet.

The Problem: One Token, Everyone

When you set up an MCP workspace for your team, you generate one Bearer token. That token goes into every team member's AI client configuration. Claude Desktop, Cursor, Windsurf — they all use the same token to authenticate against your MCP servers.

This means every team member has identical access to every MCP tool in your workspace.

Your junior developer has the same permissions as your principal engineer. Your intern can call the deployment tools. Your contractor can query the production database. There is no way to say "Alice can use the database tools but not the CI/CD tools" — not without managing separate workspaces per person, which defeats the purpose of a shared workspace entirely.

This is not a preference problem. It is a security architecture problem. And it gets worse.

The Revocation Problem

Imagine someone leaves the team. To revoke their access, you rotate the workspace token. Now you have to update the configuration of every AI client on the team. Every developer. Every machine. Every client app. Simultaneously.

In a team of ten people, this is painful. In a team of fifty, it is a production incident.

What Proper Access Control Looks Like

Enterprise security operates on the principle of least privilege. Every actor gets access to exactly what they need to do their job — and nothing else. When someone leaves, you revoke their access specifically, without affecting anyone else.

For MCP, this means per-member tokens and per-member tool allowlists.

How MCPNest Gateway Layer 2 Works

We built Gateway Layer 2 to solve this at the infrastructure level, not the application level.

Per-member Bearer tokens. Every workspace member gets their own token. The workspace token still exists for system-level access, but individual members authenticate with their own credentials. The audit trail captures member_id on every call — you know exactly who called what tool and when.

Tool allowlists per member. Admins define exactly which tools each member is permitted to call. Alice gets the database tools. Bob gets the search and retrieval tools. The deployment tools are restricted to the engineers who should have them. These allowlists are configured in the Security tab of the workspace UI — no code required.

Enforcement toggle. The workspace owner enables or disables allowlist enforcement with a single toggle. You define the allowlists first, verify they are correct, and then enable enforcement when ready.

Instant revocation. When someone leaves the team, you delete their token. Their access is gone in seconds. Nobody else is affected. No workspace token rotation. No client reconfiguration across the team.

The Audit Trail

Every tools/call through the MCPNest Gateway is logged with:

Field	Description
`workspace_id`	Which workspace
`member_id`	Which team member
`tool_name`	Which tool was called
`latency_ms`	How long the call took
`status`	Success or failure

This is not workspace-level logging. This is tool-level forensics. When something goes wrong — and in production, something always goes wrong — you know exactly what happened, who triggered it, and when.

Why This Matters Now

The MCP ecosystem is at the same inflection point that OAuth was at in 2010. Teams are moving from "I set this up on my laptop" to "we are running this in production for the whole engineering org." The security model needs to evolve at the same pace.

Right now, most teams are one credential leak away from full workspace exposure. One misconfigured client. One developer who stored their token in a public dotfile. One contractor whose access should have been revoked three months ago.

Per-member access control is not a nice-to-have for enterprise MCP deployments. It is the minimum viable security posture for any team taking this seriously.

MCPNest is the governance layer for MCP servers — Gateway, Layer 2 access control, hosted MCP infrastructure, and a marketplace of 7,554+ servers.

mcpnest.io

Ricardo Rodrigues is the founder of MCPNest and a Platform Engineer at a large financial institution in Portugal.

Why MCP Needs a Governance Layer

Ricardo Rodrigues — Thu, 14 May 2026 12:53:58 +0000

The MCP ecosystem is at an inflection point. What started as a protocol for connecting AI assistants to external tools has become the default integration layer for a generation of AI-powered engineering tools — Claude, Cursor, Windsurf, GitHub Copilot. Thousands of MCP servers exist. Tens of thousands of developers have installed them.

Almost none of them have thought about what happens when this goes to production.

The Individual Problem Is Solved

For a solo developer, MCP is close to perfect. You find a server, copy a JSON snippet, paste it into your config file, restart your AI client, and you have a new capability. GitHub integration, database access, Slack messaging, web search — all available in natural language. The friction is low enough that exploration is easy.

The MCP ecosystem solved the individual problem well.

The Team Problem Is Not

The moment a second person joins, the model breaks.

Authentication. You have a workspace token. You share it with your team. Now everyone has the same access to every tool. You cannot differentiate between what Alice is allowed to do and what Bob is allowed to do. You cannot revoke Bob's access without rotating the token — which breaks every AI client on the team simultaneously.

Deployment. Most MCP servers run as local stdio processes via npx. They exist only on the machine where they were installed. They cannot be shared across a team. They cannot be put behind a gateway. They cannot be monitored or audited. When a developer leaves, their MCP servers leave with them.

Visibility. When something goes wrong — when a production database gets queried unexpectedly, when a CI/CD pipeline is triggered by an agent, when sensitive data appears in a context where it should not — you cannot answer the most basic post-incident question: "which agent called which tool, and when?" There is no log. There is no audit trail. There is no answer.

Quality. 7,500+ MCP servers exist. GitHub stars measure historical interest, not current health. A server with 3,000 stars may not have had a commit in 18 months. There is no quality signal. There is no trust layer.

Why This Matters Now

AI agents are moving toward production infrastructure. They are not just answering questions — they are writing code, querying databases, triggering deployments, sending messages. The tools they use via MCP are real tools with real access to real systems.

The governance problem is not theoretical. It is the same problem that made API keys dangerous before OAuth, that made server access chaotic before centralised identity providers, that made network access ungovernable before Zero Trust. Every time a powerful capability becomes accessible to teams, governance follows — because it has to.

MCP is at the API key moment. The capability exists. The governance does not.

What Governance for MCP Looks Like

A governance layer for MCP needs to answer four questions consistently:

1. Who is using which tools?
Every tool call must be attributable to a specific person. Not "the workspace called something" — "Alice called the database query tool." Member-level attribution requires per-member tokens and protocol-level logging.

2. What is each person allowed to do?
Access control must operate at the tool level, not the workspace level. The security engineer should not have the same MCP permissions as the junior developer. Tool allowlists per member enforce least privilege at the protocol layer.

3. How do you revoke access instantly?
When someone leaves the team, their access must be gone in seconds. Without touching anyone else's configuration. Without rotating credentials that break the whole team. Per-member tokens make this possible.

4. Where do the servers run?
Local stdio processes are ungovernable by design. MCP servers need to run in isolated environments with defined lifecycles — deployable, monitorable, and terminatable without touching developer machines.

The Category That Does Not Exist Yet

Enterprise MCP governance is not a product category yet. It will be.

The same pattern has played out in every previous infrastructure layer. API management was chaos before control planes emerged. Identity was chaos before centralised providers. Network access was chaos before Zero Trust made it manageable.

MCP is the next layer. The governance problem is structural, not optional. And the window to define this category is open now — before the major platforms build their own solutions, before the ecosystem consolidates, before the standard emerges.

The teams that govern MCP today will not be scrambling to retrofit security into production deployments tomorrow.

Ricardo Rodrigues is the founder of MCPNest.io and a Platform Engineer at a large financial institution in Portugal. MCPNest.io is the enterprise governance layer for MCP servers — Gateway, per-member access control, hosted infrastructure, and audit logging.

mcpnest.io

From Developer Laptops to Isolated Containers — Enterprise MCP Infrastructure with MCPNest

Ricardo Rodrigues — Sat, 09 May 2026 22:56:00 +0000

The Problem

The MCP ecosystem is growing fast. Anthropic, Microsoft, Google, AWS, and Cloudflare are all publishing official MCP servers. Developers are connecting AI tools — Claude, Cursor, Windsurf — to databases, internal APIs, GitHub, and business systems.

The infrastructure for doing this at an individual level is mature. The infrastructure for doing this at an enterprise level does not exist.

Today, at most engineering teams, MCP servers run on developer laptops via npx. This means:

Credentials stored in JSON files on individual machines
No isolation between the MCP server and the host system
No central visibility into what is running
No clean offboarding when a developer leaves
No audit trail of what tools were called or what data was accessed This is not a theoretical risk. It is the default state of every engineering team that has adopted MCP tooling without a governance layer.

What We Built

The MCPNest Orchestrator is the infrastructure layer that fixes this.

Instead of running MCP servers locally, the Orchestrator manages isolated Docker containers on central infrastructure. Developers deploy from the workspace dashboard. The AI client connects to the MCPNest Gateway, which authenticates the request, checks the tool allowlist, and proxies to the hosted container.

Nothing changes in the developer workflow. Everything changes in visibility and control.

The Architecture

Claude / Cursor / Windsurf
  ↓ Bearer mng_xxx (per-member token)
MCPNest Gateway (Next.js on Vercel)
  ↓ Auth + allowlist check + audit log
MCPNest Orchestrator (FastAPI on Hetzner, Nuremberg EU)
  ↓ Docker socket
MCP Bridge Container
  ↓ stdio
MCP Server (npx package)

The Gateway handles authentication and authorisation. The Orchestrator handles the container lifecycle. The Bridge handles protocol translation between HTTP and stdio.

The MCP Bridge

Most MCP servers speak stdio — they expect to be launched as a subprocess and communicate via stdin/stdout. The Gateway speaks HTTP.

The Bridge is a FastAPI application that wraps any stdio MCP server as an HTTP endpoint. It launches the MCP server as a subprocess on startup, performs the MCP handshake, and exposes two HTTP endpoints:

POST /tools/list — returns the server tool definitions
POST /tools/call — proxies a tool call to the subprocess The Bridge image pre-installs 12 MCP server packages to avoid cold-start delays:

@modelcontextprotocol/server-filesystem
@modelcontextprotocol/server-github
@modelcontextprotocol/server-postgres
@modelcontextprotocol/server-memory
@modelcontextprotocol/server-everything
@modelcontextprotocol/server-sequential-thinking
@modelcontextprotocol/server-brave-search
@modelcontextprotocol/server-slack
@modelcontextprotocol/server-puppeteer
@upstash/context7-mcp
@notionhq/notion-mcp-server
mcp-server-sqlite

The server to run is passed via the MCP_COMMAND environment variable. The Bridge reads it on startup using shlex.split, launches the subprocess, performs the MCP initialize handshake, and begins listening on port 8080.

If the subprocess closes stdout before the handshake completes — which happens when a server requires credentials that were not provided — the Bridge raises a RuntimeError and the container exits. This is by design: servers that require credentials must have them configured before deploy.

Container Security

Every container the Orchestrator starts is hardened at the Docker level.

cap_drop ALL
Removes all Linux capabilities from the container. The MCP server process has zero elevated permissions. It cannot bind to privileged ports, modify network interfaces, or perform any operation that requires elevated access.

no-new-privileges
Prevents the process from gaining additional privileges via setuid binaries or file capabilities. Even if the MCP server package contains a setuid binary, it cannot use it.

Resource limits
CPU and memory limits are enforced per container based on the resource profile (small / medium / large). This prevents runaway processes and resource exhaustion that could affect other containers on the same host.

Dedicated Docker network
All hosted containers run on a dedicated Docker network (mcpnest_hosted), isolated from the host network. Containers cannot reach the host network directly.

Non-root user
The Bridge runs as a non-root bridge user inside the container. The MCP server subprocess inherits this user context.

Credential isolation
Credentials are passed as environment variables to the container at deploy time. They are never logged by the Orchestrator (explicitly excluded from logs), never stored in plain text in the database, and never visible to developers after submission.

Credential Management

Not all MCP servers start cleanly without configuration. Servers like the GitHub MCP server require a Personal Access Token. The PostgreSQL server requires a connection string. Slack requires a bot token and team ID.

Without credential management, these servers fail silently — the subprocess closes stdout before the handshake completes and the container exits with an error that is difficult to diagnose.

We solved this with a required_env_vars column in the mcp_allowed_images table. Each entry defines the credentials a server needs, with a key, label, type (text or password), and help text.

When a developer clicks Deploy on a server that has required credentials, a modal opens before the deploy request is sent. The modal collects the values — clearly labelled, with help text, password inputs masked. Only when all required fields are filled can the developer proceed.

The values are passed directly to the Orchestrator in the deploy request body and injected as environment variables into the container. They are never written to disk on the host and never appear in Orchestrator logs.

When a developer's access is revoked, their Bearer token is invalidated at the Gateway level. The hosted containers continue running for other team members unaffected. The credentials inside the containers are not exposed.

Deploy Flow

The full flow from click to running container:

Developer clicks Deploy in the workspace Hosted tab
If the server has required_env_vars, a modal collects the credentials before the request is sent
A POST /api/hosted request goes to the Next.js API route with the server slug and credentials
The API route creates an instance record in Supabase with status starting and forwards the deploy request to the Orchestrator
The Orchestrator checks if the Bridge image is already present locally using docker.images.get() — skips pull if found, pulls only if not cached
The Orchestrator starts the container with cap_drop ALL, no-new-privileges, resource limits, and the credentials as environment variables
The Orchestrator updates the instance record in Supabase with status running and the assigned host port
The Next.js API route returns the instance_id to the client
The workspace UI opens a terminal modal that polls /api/hosted/{id}/logs every 3 seconds
When the container reaches RUNNING + HEALTHY state (Docker health check passing), the modal updates automatically and stops polling The real-time deploy console shows the container logs as they stream. The developer sees the MCP server startup output — including any errors — in real time. There is no need to SSH into the server or use Docker CLI.

The Pull-Skip Optimisation

Early in development, every deploy attempt pulled the Bridge image from the registry, even though the image is local-only and was never pushed to Docker Hub. This caused every deploy to fail with a pull access denied error.

The fix was simple but important: check if the image exists locally before attempting a pull.

try:
    cli.images.get(req.image)
    logger.info("Image %s already present locally, skipping pull", req.image)
except Exception:
    try:
        await asyncio.get_event_loop().run_in_executor(
            None, lambda: cli.images.pull(req.image)
        )
    except Exception as exc:
        raise RuntimeError(f"Failed to pull image {req.image!r}: {exc}") from exc

This also makes deploys faster — there is no network round-trip for images that are already cached on the host.

What This Gives Enterprise Teams

Isolation
MCP servers run in sandboxed containers. A misconfigured or compromised server cannot access the host system or interfere with other containers.

Central credential management
No credentials on developer machines. No JSON files with GitHub tokens or database connection strings on laptops. Clean offboarding — when a developer leaves, their Gateway token is revoked and their access is gone immediately.

Audit trail
Every tool call is logged at the Gateway level — member, server, tool name, latency, HTTP status, timestamp. No inputs or outputs are stored. GDPR safe by design.

Consistent infrastructure
Every developer on the team deploys from the same verified catalog. No drift between machines, no manual setup, no "works on my machine" issues with MCP server configuration.

Visibility
Real-time deploy logs during startup. Per-instance log viewer for ongoing debugging. Health monitoring with automatic RUNNING + HEALTHY detection. Terminate with full cleanup — container removed, database record updated.

Current State

The Orchestrator runs on a dedicated Hetzner server in Nuremberg, EU. All state is managed in Supabase (Frankfurt, EU). The Gateway runs on Vercel's edge network.

12 verified MCP servers are available in the hosted catalog today: filesystem, GitHub, PostgreSQL, Notion, Context7, Slack, SQLite, Brave Search, Puppeteer, Memory, Sequential Thinking, Everything.

SOC 2 Type 1 is planned. Self-host via Docker is available for teams that require on-premise deployment.

Conclusion

The MCP ecosystem is at the same inflection point that npm was in 2012 — growing fast, with tooling that works well for individuals and not yet for enterprises.

The gap is not in the protocol. The protocol is solid. The gap is in infrastructure, governance, and auditability.

Running MCP servers on developer laptops is the path of least resistance. It works until it doesn't — until a developer leaves with credentials, until a server is misconfigured and accesses something it shouldn't, until a security team asks what tools the AI has been calling and nobody can answer.

The MCPNest Orchestrator is the infrastructure layer that closes that gap.

mcpnest.io

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