Back to Home

AnythingMCP vs writing a custom MCP server — build or buy

When does it make sense to write your own MCP server vs use a gateway like AnythingMCP? Real numbers, real boilerplate, decision framework.

Every AI-savvy team eventually asks: should we write our own MCP server with the official Anthropic SDK, or use a gateway like AnythingMCP?

This page is the build-vs-buy answer, written by people who've shipped both.

TL;DR

  • Write your own if you have one API to expose, a strong reason to optimise for that specific shape (custom transport, exotic streaming, weird auth), and a team comfortable maintaining MCP-spec compliance over time.
  • Use AnythingMCP if you have two or more APIs, want governance/audit/RBAC out of the box, or care about not rewriting the same boilerplate per service.

What "custom" means in practice

A minimum-viable custom MCP server in TypeScript:

import { Server } from "@modelcontextprotocol/sdk/server";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/transport/streamable-http";

const server = new Server({ name: "my-api-mcp", version: "1.0.0" });

server.tool("getCustomer", "Look up a customer by ID", {
  customerId: { type: "string", description: "Customer UUID" },
}, async ({ customerId }) => {
  // Auth (TODO)
  // Logging (TODO)
  // Audit (TODO)
  // Error mapping (TODO)
  const res = await fetch(`https://api.example.com/customers/${customerId}`, {
    headers: { Authorization: `Bearer ${process.env.API_TOKEN}` },
  });
  return { content: [{ type: "text", text: await res.text() }] };
});

const transport = new StreamableHTTPServerTransport({ port: 3000 });
await server.connect(transport);

This works. For one tool. For one user. For one environment. With env-var auth.

In production you also need:

  • OAuth2 (PKCE + Client Credentials), Bearer, API Key, Basic, WS-Security, TLS certs
  • AES-256-GCM credential storage with key rotation
  • Audit log of every tool invocation (who, when, input, output, duration)
  • Per-user MCP API keys with usage tracking
  • RBAC (sales team sees different tools than engineering)
  • Rate limiting per role
  • Tool versioning so AI clients don't break on your refactor
  • Health checks, metrics, error reporting (Sentry/OTel)
  • Docker image, Helm chart, CI/CD
  • Documentation, runbooks, on-call rotation

This is the 80% of code that's identical across every MCP server anyone writes. AnythingMCP is the result of writing it once for ourselves.

Side-by-side

| | AnythingMCP | Custom MCP server | |---|:---:|:---:| | Time to first MCP tool | ~5 min (paste OpenAPI URL) | ~1-3 days (set up project + auth + transport) | | Time to add another connector | ~5 min | ~1-3 days each | | Boilerplate code per service | 0 lines | ~500-2000 lines | | OAuth2 PKCE + Client Credentials | ✅ Built-in | DIY | | Audit log | ✅ Built-in | DIY | | RBAC | ✅ Built-in | DIY | | Per-user MCP API keys | ✅ Built-in | DIY | | Credential encryption at rest | ✅ AES-256-GCM | DIY | | MCP spec compliance (transport, capabilities, errors) | ✅ Maintained | DIY (and you'll update it as the spec evolves) | | SOAP / WSDL parsing | ✅ Built-in | Significant work | | Database introspection | ✅ 7 engines | DIY per engine | | Visual tool editor | ✅ | DIY | | Code ownership | Your adapter JSON files | All of it | | MCP version updates | We handle in each release | You track + patch | | Total cost over 12 months for 5 services | ~€240 (small VPS or cloud plan) | ~3-8 engineer-weeks (€10k-€30k) |

When custom is the right call

You should write your own MCP server if:

  1. One service, one team, one auth model. Single API, single team, no governance need beyond a Bearer token. The boilerplate cost amortises poorly.
  2. Exotic transport requirements. You need WebSocket-style bidirectional streaming, stdio for local-only desktop integration, or some custom transport. AnythingMCP focuses on Streamable HTTP — if you need stdio for a Claude Desktop extension specifically, write a small custom server.
  3. Hyper-optimised for LLM call patterns. You've measured your specific Claude/GPT call traces and your tool descriptions/parameter schemas need to be hand-tuned beyond what JSON adapter files allow. Rare, but legitimate.
  4. Team prefers code over config. Some teams genuinely move faster writing TypeScript than writing JSON. If you're one of them, the SDK is fine.

When AnythingMCP is the right call

  • You have 2+ APIs/services to expose
  • You need any of: OAuth2 flows / RBAC / audit / per-user keys / credential encryption
  • You have legacy SOAP services or direct database access
  • You want a visual editor for non-engineers (PMs, support) to define tools
  • You don't want to keep up with MCP spec evolution yourself
  • The amount of unique business logic is < 20% of the boilerplate

Migration path

If you've already started a custom MCP server, you don't have to throw it away. AnythingMCP can front your custom server as one of many MCP sources via the MCP-to-MCP bridge. New connectors go into AnythingMCP; the custom one keeps doing its thing until you want to migrate it (or not).

The honest part

AnythingMCP didn't exist when we started building MCP servers in late 2024. We wrote 5 custom ones. After the third, we noticed the pattern. After the fifth, we extracted the shared infrastructure. After 6 months of running it in production at a German industrial group, we open-sourced it.

If you want to skip the same path, save yourself a few engineer-weeks:

git clone https://github.com/HelpCode-ai/anythingmcp.git
cd anythingmcp && ./setup.sh

Star on GitHub if this was useful. PRs welcome.