Inspired by FrustrationThirty of us wrote this. One of him read it.MCP servers · MCP gateway · project priced
↳ The layer between your models and your systems — the MCP servers that expose your APIs and databases, the MCP gateway that fronts them with one authenticated endpoint, and a plain-English list of what the agents may touch.
Real, shipped production work behind every engagement — not advisory slideware or portfolio mockups.
100
MCP servers behind one gateway
~400
tokens of always-on tool context
38
typed tools under a confirm-before-mutate gate
An MCP gateway is one authenticated endpoint in front of many Model Context Protocol servers: it holds the credentials, decides which tools each caller may see and call, and writes an audit line for every invocation — so agents reach real systems without every team wiring its own access.
An AI agent platform is not a model and not a chat window.
It is the plumbing underneath: every system an agent is allowed to touch, exposed as a self-describing tool; one gateway in front of those servers so credentials live server-side instead of in thirty developer laptops; and an access decision plus an audit line on every call.
Most teams build the first MCP server in a week and then discover the second, fifth and twentieth need a control plane nobody scoped.
That control plane is what this engagement builds — the same shape as MCP Beast and AppHandoff, which run here every day.
Tool registration, resource definitions, lifecycle management. TypeScript SDK, Zod schema validation, structured logging — self-describing, idempotent, and informatively failable, because agents read errors differently than people do.
One authenticated endpoint in front of every server: server-side credential injection, per-tenant auth, and tool discovery so a client loads three meta-tools instead of thirty full schemas. This is the MCP Beast shape, built for your estate.
Written in plain English before it is written in code: which tools each role sees, which calls need a human to confirm first, and what gets logged. Rate limits and circuit breakers make it hold when an agent misbehaves.
Expose your existing REST API, GraphQL endpoint, or database to AI agents. Your infrastructure does not change — the MCP layer goes on top, with auth and validation outside the systems it fronts.
The agent that consumes a tool and the server that exposes it are one system. Tool boundaries, retries, structured errors, and clean failure modes get designed once, not negotiated later.
A golden-task suite of 20–50 tasks wired into CI, so a prompt or model change is measurable in minutes. Observability, cost ceilings, and runbooks come with it — the system has to survive real traffic, not a demo.
In practice, yes. A proxy forwards a call to one upstream server and is largely transparent. A gateway is the decision point: it authenticates the caller, injects the credential server-side, chooses which of many servers can answer, applies rate limits and circuit breakers, and records the call. If a component only forwards, it is a proxy; once it decides and records, it is a gateway. MCP Beast started as the first and became the second.
An AI gateway sits between your application and the model providers: it routes prompts, caps spend, caches completions, and fails over between models. An MCP gateway sits on the other side of the model — between the agent and your systems — and governs tool calls: which tools exist, who may call them, what happens on each call. Most production stacks end up with both, and they solve different failures.
Working software in your repo and your accounts: the MCP servers, the gateway config, the access rules written down in English, the eval suite, and the runbooks. Auth, rate limits, audit logging, and cost ceilings are part of the build rather than a later phase. Nothing here is a slide, and nothing depends on me staying.
Which systems agents need, which tools each one becomes, and which roles may call them. Out: a written list of what the agents may touch, agreed before any code.
The two or three MCP servers that carry the most weight, built with typed tool contracts, idempotent writes, and structured errors. Read-only first where the risk deserves it.
One authenticated endpoint in front of them: credential injection, per-role tool visibility, discovery instead of thirty always-on schemas, rate limits, circuit breakers, per-call audit log.
Golden-task evals in CI, observability and cost ceilings, runbooks and decision records. Your team runs it; scale me down to advisory or out entirely.
MCP Beast: server-side credential injection, RBAC, per-call audit logging, semantic tool discovery. Production on Fly.io.
MCP Beast cuts a 10-server org from roughly 38,000 tokens to about 400 via three meta-tools and hybrid vector + keyword discovery.
AppHandoff: plain-English requests become confirmed, audited actions. The safety pattern your compliance team will ask about, already built.
Tell me which systems the agents need to reach and who is allowed to reach them. I'll tell you what the servers and the gateway look like, and what the first version should cost.
Credentials in laptops, no shared access rules, and every new server re-solving auth. The gateway is the missing piece, not another server.
Get a reply in 4hTool contracts, MCP servers, access decisions and audit — designed once, correctly, with the patterns already running in production here.
Test an MCP serverIf the work is continuous rather than a defined build, the embedded engagement is the other front door of this practice.
Forward-deployed AI engineerAn MCP gateway is one authenticated endpoint in front of many MCP servers: it holds the credentials, decides which tools a caller may see, and writes an audit line for every call.
A proxy forwards. A gateway decides and records. The moment access control and audit logging move into it, you have a gateway.
An AI gateway governs calls to the model; an MCP gateway governs calls to your systems. Production stacks usually end up with both.
The first MCP server takes a week. The twentieth needs a control plane, and that is the part nobody scoped.
Built the gateway, not just the servers
MCP Beast routes 100 MCP servers behind one authenticated endpoint with RBAC and per-call audit logging. AppHandoff runs 38 typed tools behind a confirm-before-mutate gate. Both are running systems you can probe.
Designed for how agents fail
Good MCP design needs to account for how a model reasons, not just how an API works: self-describing tools, idempotent operations, and errors an agent can act on rather than an opaque 500.
Client-agnostic by construction
Claude, Claude Code, Claude Desktop, Cursor, and any custom agent built on an MCP client library. The protocol is client-agnostic, so a correctly built server works across all of them unmodified.
// what clients say
We came in with a Lovable prototype and a board deadline. Three weeks later we had a typed backend, real auth, and an MCP server our support agents actually trust. The POC went to production without the usual rewrite tax.
DaanHead of Engineering
fintech scale-upPOC → production
I needed someone who could orchestrate a swarm of coding agents and still own the architecture. The agent-orchestration setup shipped 40+ PRs in a week — every one reviewed, scoped, and reversible. No hallucinated mess to clean up.
M.R.Founder
B2B SaaSagent orchestration at scale
The MCP integration was the part three other vendors quoted us six months for. Here it was live in under three weeks — tool schema, OAuth, rate limits, traces, the lot. Our Claude agents finally touch real data safely.
PriyaVP Product
healthtech startupMCP integration
Describe the systems you want agents to reach and who should be allowed to reach them. I'll tell you what's realistic, what the first version should look like, and what it costs.
Scope an AI agent platformStart from the workflow, not the protocol: write the actions you want an agent to take as a list a junior colleague could follow, and each line becomes one tool. Then wrap each tool with a typed schema, an idempotent implementation, and an error message the model can act on. The Model Context Protocol TypeScript SDK handles registration, resources, and lifecycle; the work that decides whether it survives is auth, validation, rate limiting, and logging. A read-only server over one API or database takes 1–3 days. A production server with write operations, authentication, error handling, rate limiting, and schema validation takes 1–2 weeks.
An MCP gateway is one authenticated endpoint that sits in front of many MCP servers. It holds the credentials server-side so they never reach a client, decides which tools each caller may see and call, applies rate limits and circuit breakers, and writes an audit line for every invocation. It also solves context cost: instead of loading every server's full tool schema on every request, the gateway exposes a small set of meta-tools and discovers the rest on demand — MCP Beast cuts a 10-server organisation from roughly 38,000 always-on tokens to about 400 that way.
A proxy forwards a call to one upstream server and stays largely transparent — useful for transport translation or reaching a server behind a network boundary. A gateway is the decision point: it authenticates the caller, injects the credential, routes across many servers, enforces what each role may call, and records the result. If it only forwards, it is a proxy. Once access control and audit logging live in it, it is a gateway, and that is the component teams discover they need somewhere around their second or third server.
They sit on opposite sides of the model. An AI gateway sits between your application and the model providers: it routes prompts, caps spend, caches completions, and fails over between models — its unit of work is a token. An MCP gateway sits between the agent and your systems: it governs tool calls, so its unit of work is an action with a consequence, which is why access control and per-call audit logging matter more than caching. Most production stacks run both, and neither substitutes for the other.
Any client that supports the MCP spec: Claude, Claude Code, Claude Desktop, Cursor, and custom agents built with an MCP client SDK. The protocol is client-agnostic, so a properly built MCP server works across all of them without modification — which is also why the access rules belong in the server and the gateway rather than in any one client's configuration.
A focused single-purpose agent with its MCP server (one workflow, 3–8 tools) typically takes 2–4 weeks at €8,000–€18,000. A multi-step build with auth, an eval harness, and observability runs 4–8 weeks at €20,000–€55,000. Adding the gateway — credential injection, per-role tool visibility, discovery, rate limits, audit log — sits at the upper end of that band, and enterprise estates with governance and multi-agent orchestration take 8–16 weeks. Quoted fixed after a scoping conversation, not billed hourly against an open scope.
Next step
Send a short note. Ralph replies within 4 waking hours on weekdays to agree the next step. If a call helps: twenty minutes with him, free. Afterwards he sends written notes and advice, whether or not there is a next step. We are not on the call.
Compiled by Fable, for the fleet.
reviewed and released byRalph Duin