← Entitees AI Blog · Entities · Pricing · Embed

Blog

What a production MCP server actually needs

· 7 min read

Building your first MCP server takes an afternoon. Install the SDK, define a tool, point an assistant at it, watch it call your code. It genuinely is that quick, and that is the best thing about the Model Context Protocol.

It is also why so many of them never leave the laptop.

The distance between a server that works on your machine and one you can put in front of a paying customer is not more tools. It is everything around the tools — and none of it is in the protocol, because none of it belongs in a protocol.

What MCP gives you, and what it deliberately doesn't

The Model Context Protocol is how an assistant reaches something it does not have in front of it: your systems, your data, your internal tools, through one interface instead of a bespoke integration for every pairing.

What it standardises:

That is a lot, and it is genuinely all most people need to get started.

What it does not say a word about:

None of that is an oversight. A protocol that also dictated your auth model would be a worse protocol. But it does mean that every team shipping a commercial MCP server writes the same several thousand lines before they write anything that makes their product theirs.

The list that never makes it into the demo

Here is what actually sits between a working tool and a sellable one.

Authentication. API keys are fine, as long as you store hashes and not the keys. Enterprise buyers will ask for OAuth 2.1 and will know what JWKS and RFC 9728 are. Then you need roles on top — a read-only integration should not be able to call the tool that writes.

Multi-tenancy. This is the one that bites later rather than sooner. Every rate limit, every quota, every cache key and every audit line has to be scoped to a tenant. Retrofitting that into a server that assumed one customer is a rewrite, not a refactor, because the assumption is in every function signature.

Rate limits and quotas. Not only to stop abuse. Per-tenant, per-tool metering is the mechanism underneath usage-based pricing — if you cannot count it, you cannot charge for it.

Audit logging. Every call recorded, with PII and secrets redacted before they reach disk rather than scrubbed afterwards. The first time a customer asks what your AI did on their account, this is the only acceptable answer.

Observability. Structured logs, p50/p95/p99 latency per tool, health and readiness probes. "It feels slow" is not a bug report you can act on.

Reliability. A thrown error inside one tool must never take the server down. That means per-tool timeouts, retries, a circuit breaker on anything calling out, and an error boundary that holds.

An admin surface. Someone non-technical will eventually need to mint a key, revoke a key, see what a tenant has been doing, and raise a quota — without you SSHing into a box.

The pattern that matters more than any single feature

You can build all of the above and still end up with a fragile server, because of where the checks live.

The failure mode is scattered enforcement. Tool one checks the role. Tool two checks the role and the quota. Tool seven was written in a hurry during a customer trial and checks neither. Nothing is obviously broken, no test fails, and you find out when the bill arrives or the auditor asks.

The fix is to make the pipeline impossible to skip: a single wrapper that every tool goes through, so the business logic is inherited rather than remembered.

RBAC → rate limit → quota → cache → timeout → error boundary
         (+ metrics, audit logging and webhooks on every call)

Write the tool, wrap it, and it has all of that. Automatically, every time, with no way to forget — including for the tool someone adds six months from now who has never read this list.

That is the architectural argument, and it is the reason a starter is worth more than a tutorial. A tutorial shows you the pieces. A starter has already decided how they fit together.

MCP Pillar

MCP Pillar is that scaffolding, built and tested, for $199.

It is a complete, typed TypeScript codebase on the official @modelcontextprotocol/sdk — zero-config to run locally, one command to deploy. You get the source repository and run it on your own infrastructure. No telemetry, nothing phones home.

The protocol layer. stdio and Streamable HTTP from one codebase, switched by a flag. Tools, resources (static and dynamic templates) and prompts, with working examples for synchronous, async-with-retry, progress-streaming and structured-output tools.

The business layer. Hashed API keys and full OAuth 2.1 with RBAC enforced per tool. Per-tenant scoping on every limit, quota, cache key and audit line. Token-bucket rate limiting and monthly quotas. Audit logs with PII and secret redaction. Structured logging, p50/p95/p99 metrics, an optional Prometheus endpoint, and health and readiness probes.

The parts you would not have got round to building. A built-in admin dashboard with a live tool-call feed, usage and latency analytics with CSV export, tenant quotas and API-key minting and revocation. Declarative per-tool response caching. HMAC-signed webhooks. Hot reload in development. A scaffolding CLI that generates a fully tested, registered tool in seconds. A reliability toolkit of circuit breakers, per-tool timeouts, retries and sanitizers.

Shipping it. Set REDIS_URL and the rate limits, quotas and cache go distributed across instances. A multi-stage Dockerfile, a docker-compose stack with Redis and Postgres, GitHub Actions CI and tagged releases. Deploy guides for Fly.io, Railway, AWS ECS and a bare VPS.

Evidence it works. 119 tests at 91% coverage behind an enforced gate, with integration tests driving the real server through a real MCP client. Validated with the official MCP Inspector over both stdio and HTTP. One command — npm run verify — lints, typechecks, tests, builds, and boots the compiled server to confirm it still speaks MCP. Green means it works.

The stack is TypeScript on Node 20+, Express, Zod-validated config and pino logging, with Redis optional. Fully typed, fully tested, no lock-in.

One licence covers unlimited projects and products within your organisation, commercial ones included. You keep every version you receive, forever. The only thing you cannot do is resell the template itself.

FAQ

What is an MCP server?

A server that exposes tools, data and prompts to an AI assistant over the Model Context Protocol, so the assistant can reach systems it does not otherwise have access to. One interface, rather than a custom integration per assistant.

Does my MCP server need authentication?

If it runs locally over stdio and only you use it, no. The moment it is reachable over HTTP, or more than one person or customer uses it, yes — and you will want roles as well as identity, so a read-only integration cannot call a tool that writes.

Why is multi-tenancy hard to add later?

Because the assumption that there is only one customer ends up inside every function signature, cache key and log line. Adding tenancy afterwards means touching all of them at once, which is a rewrite rather than a refactor.

Can I use MCP Pillar in a commercial product?

Yes. One licence covers unlimited projects and products within your organisation, including commercial ones. You cannot resell the template itself.

What does MCP Pillar cost, and what do I get?

$199 for the complete source repository — every module described above, the full test suite, Docker and CI config, and docs covering architecture, security, extending, deployment and an auto-generated tool reference. You run it on your own infrastructure.

What is it built with?

TypeScript on Node 20+, the official @modelcontextprotocol/sdk, Express, Zod-validated config and pino logging, with optional Redis for distributed limits and caching.

Building something that needs to reach your own systems? Tell us what you are trying to connect and we will tell you honestly whether this is the right shape for it.

← All articles