AnythingMCP vs writing a custom MCP server: build or buy

Every team that takes AI agents seriously eventually asks the same question: should we write our own MCP server with the official SDK, or use a gateway like AnythingMCP?

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

TL;DR

• Write your own if you have one API to expose, a strong reason to optimise for its exact shape (custom transport, unusual streaming, unusual auth), and a team that will keep up with the MCP spec over time.
• Use AnythingMCP if you have two or more systems, want roles, audit and rate limits out of the box, or do not want to rewrite the same boilerplate for every service. 713 ready connectors with 12,000+ tools cover most common systems already, and any REST, SOAP, GraphQL, OData or SQL source becomes MCP tools without code.

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, one user, one environment, with a token in an environment variable.

In production you also need:

• OAuth 2.0 for the AI clients, plus OAuth2, Bearer, API key, Basic, WS-Security or TLS client certificates towards the upstream system
• Encrypted credential storage (AnythingMCP uses AES-256-GCM)
• An audit log of every tool call: who, when, input, output, duration
• Per-user MCP API keys with revocation
• Roles, so sales sees different tools than engineering
• Rate limits per tool and role, so one runaway agent cannot hammer your ERP
• Response mapping, so fields that must not reach the model are dropped first
• Tool versioning, so AI clients do not break on your refactor
• Health checks, metrics, error reporting
• A Docker image, CI/CD, documentation and someone on call

This is the shared 80% that is the same in every MCP server anyone writes. AnythingMCP is the result of writing it once.

Side by side

When custom is the right call

You should write your own MCP server if:

1. One service, one team, one auth model. A single API and no governance need beyond a token. The gateway's shared layer has little to amortise.
2. Exotic transport. You need stdio for a local desktop extension, or a custom transport. AnythingMCP serves remote MCP over Streamable HTTP. For a local-only Claude Desktop extension, a small custom server is the simpler path.
3. Hand-tuned tool design. You have measured your Claude or GPT call traces and need tool shapes beyond what a declarative definition allows. Rare, but legitimate. (AnythingMCP's saved code tools cover part of this: a short program behind one tool.)
4. Your team prefers code to configuration. Some teams move faster in TypeScript than in JSON. If that is you, the SDK is fine.

When AnythingMCP is the right call

• You have two or more systems to expose, or the system is already in the connector marketplace.
• You need any of: OAuth flows, roles, audit, per-user keys, rate limits, credential encryption.
• You have legacy SOAP services or a database behind your VPN.
• You want non-engineers to adjust tool names and descriptions in a visual editor.
• You want the agent to get better over time: AI skills learned from real requests and fixed errors, approved by an admin, and a knowledge graph of how your systems connect.
• You do not want to track the MCP spec yourself.

Migration path

If you already run a custom MCP server, keep it. AnythingMCP's MCP-to-MCP bridge serves it next to your other connectors, behind the same sign-in, roles, rate limits and audit log. New systems go into AnythingMCP; the custom server keeps working until you decide to migrate it, or never.

The honest part

AnythingMCP did not exist when we started building MCP servers in late 2024. We wrote five custom ones. After the third, we saw the pattern. After the fifth, we extracted the shared infrastructure. After running it in production at a German industrial group, we open-sourced it under AGPL-3.0.

FAQ

How long does it take to build a production MCP server? One tool with a token takes an afternoon. Auth for several users, audit, roles, rate limits and deployment usually take weeks, and the work repeats for every new system unless you share the code.

Can AnythingMCP run my existing custom MCP server? Yes. The MCP-to-MCP bridge discovers its tools and serves them next to your other connectors, with the same roles and audit log.

Is AnythingMCP free? The self-hosted Community edition is free under AGPL-3.0 for any use, including commercial use, up to 3 active users. Cloud starts at €19 a month with a 7-day trial; Enterprise is quoted. See pricing.

Does AnythingMCP support stdio? No. It is a remote MCP server over Streamable HTTP, which is what Claude, ChatGPT, Copilot Studio and Cursor use for remote connectors.

Try it

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

Or start the Cloud free trial: 7 days, hosted in Frankfurt.

⭐ Star on GitHub if this was useful. PRs welcome.