The Last MCP Server You'll Ever Need

Part of our MCP series — the overview lives at MCP Server.

Count the MCP servers you have connected. GitHub, Slack, your database, your ticketing system, your monitoring, the one somebody on the team wrote for the internal API. Now count the tools they add up to.

A typical five-server setup — GitHub, Slack, Sentry, Grafana, Splunk — is 58 tools and roughly 55,000 tokens of definitions before the user has typed a character. Cursor caps you at about 40 tools across every server combined and silently drops the rest. Claude Code's output quality degrades past 50. Perplexity's CTO said tool descriptions were eating 40 to 50 percent of the context window and partially pulled MCP from internal use.

The registries are past 13,000 servers, one of them close to 20,000. The industry's answer to the pile-up is the MCP gateway: an aggregation layer that sits in front of your servers, centralises auth, and lazy-loads tool descriptions. A ninth server whose job is managing the other eight.

I think that is treating the symptom.

The wrong diagnosis

The problem was never that you have too few servers, or too many. It is what each server is.

Every one of them is a hand-built copy of something that already existed. The database server is a copy of your schema. The CRM server is a copy of the CRM's API specification. The internal-tools server is a copy of the endpoints your team already runs. Somebody read the original, typed out a tool definition per operation, wired a handler, hosted the process, and now maintains the copy while the original keeps changing underneath it.

Copies drift. Copies cost tokens, because every one of them ships its full catalogue whether you need it or not. And copies multiply, because the next system you want your agent to reach gets its own copy too.

You do not need more copies, or a gateway to organise the copies. You need one server that reads the originals.

What "anything" means

A Magic cloudlet is an MCP server, and it has no tool registry. When a client asks what tools exist, the server enumerates the endpoints on the cloudlet, right then, and describes them from the metadata already in the files. I have written up why that cannot drift, so I will not repeat it.

The consequence is the interesting part. Anything that can become an endpoint is already a tool. And on this platform, the list of things that can become an endpoint is long:

You have	It becomes a tool by	Time	Deep dive
A table in SQLite, PostgreSQL, MySQL or SQL Server	Ticking it in the CRUD generator — read, create, update, delete, count, role-gated per verb	Milliseconds	SQL Server and MySQL, step by step
A SQL statement someone runs every Monday	The SQL endpoint generator: paste the query, declare its arguments, pick a role	A minute	—
An OpenAPI specification	The Import API tab: paste the URL, tick the operations, choose a role	Seconds	OpenAPI to secured MCP tool
A sentence describing what you want	The Hyperlambda Generator writes, verifies and saves it	3.03 seconds, measured	From prompt to MCP tool
A Python script	Wrapped as an endpoint that runs it and returns its output	Minutes	—
A shell command	Wrapped the same way, gated by whatever role you choose	Minutes	—
A website with no API	A headless-browser endpoint that logs in, navigates, and reads the rendered page	Minutes	The headless browser slots
A CSV, JSON, XML or YAML file	Loaded and queried as a lightweight database	Minutes	—
A SaaS with a plugin in the Bazar — HubSpot, Shopify, Stripe, Slack, WooCommerce, WordPress, NetSuite	Installing the plugin	One click	The API magic wand
Email, scheduled tasks, files, real-time events	Platform primitives every endpoint can use	Already there	—

Every row lands in the same catalogue, behind the same OAuth flow, filtered by the same roles. The first three rows cover most of what a business actually runs on. The rest are where the word anything earns its place.

A Magic cloudlet connected inside Claude's Connectors settings, listing 220 tools it publishes with per-tool permissions

The things that never had an API

The row I care about most is the one no vendor is going to ship a server for, because there is nothing to ship a server against.

The supplier portal. A login page, a search form, a results table, built in 2011, no API, no plans for one. On Magic this becomes an endpoint that drives a headless browser: sign in with a credential held in configuration, fill the form from the endpoint's arguments, read the rendered table back as structured data. To the agent it is a tool called something like lookup-supplier-stock with two typed arguments. The portal never knew.

The model script. The pricing model, the risk score, the forecast — a Python file somebody maintains and everybody else emails to run. Wrapped as an endpoint it takes its inputs as arguments, runs the script on the cloudlet, and returns the output. The script does not change. It just becomes callable.

The nightly export. A CSV that lands in a folder at 02:00 because the system that produces it has no other door. Load it in an endpoint and it is queryable: filter, aggregate, join against a real table. The agent asks a question; the answer comes from the file.

The command-line utility. The thing only one person knows how to invoke. Wrapped as an endpoint with a role gate, it becomes a tool that person can hand to the whole department without handing over a shell.

None of these four had an API. All four are in the tool list.

Honesty about the edges: the browser route is only as stable as the page it drives, so redesigns break it and you regenerate. The script route needs its runtime on the cloudlet. The command route is something an administrator sets up deliberately, with a role on it, not something an agent grants itself — generated code cannot reach the shell, which is the whole point of the sandbox.

One server, as many servers as you need

Here is where the gateway argument collapses.

A gateway exists to give different audiences different views of a pile of servers. Magic does that with two mechanisms that were already there.

The first is roles. The tool catalogue is assembled per caller from the roles on the authenticated ticket, and the identical role check runs again when a tool is invoked. Connect the sales agent with the role that sees the CRM wrappers and it sees the CRM wrappers. Connect finance with the role that sees invoicing and it sees invoicing. Neither sees the other's tools, and neither can call them by guessing a name.

The second is the path. Append ?path=/modules/crm/ to the MCP URL and the catalogue narrows to that module and nothing else, confined inside the modules folder so a sibling cannot leak through.

Combine them and one cloudlet is as many differently-scoped MCP servers as you have audiences — per department, per agent, per client — with one OAuth flow, one host, and one place where the tools actually live. That is the product the gateway vendors are selling. It came with the backend.

Staying under the tool budget

Forty tools in Cursor. Fifty before Claude Code starts chasing tangents. The budget is real, and a server that can expose anything could bury you faster than eight vendor servers ever did.

The difference is that on Magic a tool is a file, so curation is editing. Import the twelve operations you want from an 800-operation specification, not the 800. Rename the one the model keeps picking wrongly. Delete the nine arguments nobody passes. Bake in the filter you send every time. Split one module into two so the path parameter can hand each audience a smaller belt.

And write the first sentence well, because it survives. The prompt you gave the generator becomes the description the model reads when deciding whether to call the tool. Nobody on this platform writes tool definitions, but somebody still writes that sentence, and it is you.

What you pay once

Auth, once: the cloudlet runs its own OAuth 2.1 flow, so connecting is paste a URL and authorise, with no client to register beforehand. The CRM walkthrough shows the whole dance.

Hosting, once: the MCP server is the backend. There is no ninth process.

Drift, never: there is no registry to update, so a tool cannot be added to the list. It can only be created, after which the list already contains it.

Upstream secrets, never in the agent: the credential for an imported API is read from configuration at invocation time and attached server-side. A prompt-injected agent gets the result of an authenticated call, not the key.

The honest edges

Claude's custom connectors are called from Anthropic's infrastructure, so for that client the cloudlet must be reachable from the internet. Claude Code and Cursor run on your machine and are happy with a cloudlet on localhost or inside your firewall.

Clients cache the tool list when they connect. Create a tool and it is live instantly on the server; your connector will not show it until you reconnect.

The transport is plain request/response JSON. No SSE stream, no server-initiated messages. Some clients cap tool names at 64 characters, and Magic does not truncate, so keep module paths shallow.

Keep the vendor's server where it earns its keep. If GitHub's official server has a tool you rely on, use it. The two compose: Magic endpoints are HTTP, so an agent that talks to both is normal. The claim in the title is that this is the last server you need to build, not that you must throw the others away.

Never connect as root. The role you connect an agent with is its blast radius. Give it a user and a role of its own.

Try it

One command:

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

Open localhost:5555, point it at localhost:4444, log in with root / root, and install the oauth and mcp plugins from the Plugins screen. Then hand your client the URL:

http://localhost:4444/magic/modules/mcp/mcp

Tick a table in the generator, paste a Swagger URL, or describe the tool you wish you had. Reconnect the client, and look for it.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

Eight servers, fifty-eight tools and a gateway to manage them is one way to give an agent your company. One server that reads the originals is the other.