An MCP Server Is a 50-Line File. Why Every Paid API Should Ship One.

Every conversation I have with an API team about adding a Model Context Protocol server starts the same way. They have heard MCP is a thing. They are not sure how much it costs to support. They imagine a sprawling integration that touches their auth, their billing, their observability stack. They quote me three weeks of engineering time. Then I show them the actual file and they go quiet for a minute.

The minimum-viable MCP server for an existing paid API is roughly 50 lines of TypeScript. You can write it in an afternoon and ship it the same day. The leverage is enormous: every Claude Desktop and Claude Code user becomes a one-config-edit away from your API. Most teams overthink this work, and almost everyone underestimates how much it pays back.

The actual file

Here is the entire MCP server for a hypothetical news API. It exposes one tool that returns the latest articles. Production-ready, no shortcuts.

#!/usr/bin/env node
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const API_BASE = 'https://example.com/api';

async function fetchJSON(path: string): Promise<unknown> {
  const res = await fetch(`${API_BASE}${path}`, {
    headers: { 'User-Agent': 'Example-MCP/1.0' },
  });
  if (!res.ok) throw new Error(`API error: ${res.status}`);
  return res.json();
}

const server = new McpServer({ name: 'example', version: '1.0.0' });

server.tool(
  'get_latest_news',
  'Get the latest news articles from Example.com.',
  {
    category: z.string().optional().describe('Filter by category'),
    limit: z.number().min(1).max(50).optional().describe('How many to return'),
  },
  async ({ category, limit }) => {
    const params = new URLSearchParams();
    if (category) params.set('category', category);
    if (limit) params.set('limit', String(limit));
    const data = await fetchJSON(`/news?${params}`) as {
      articles: { title: string; url: string; published: string }[];
    };
    const text = data.articles
      .map((a, i) => `${i + 1}. ${a.title} (${a.published})\n   ${a.url}`)
      .join('\n\n');
    return { content: [{ type: 'text' as const, text: text || 'No articles.' }] };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);
console.error('Example MCP server running on stdio');

That is it. 38 lines counting blanks. Add a package.json with the SDK dependency, a tsconfig.json with strict mode and ES2022, and one shell command to publish. The whole project is under 100 lines of human-written code.

What is in those 50 lines

1. A fetch helper for your API. Reuse the one you already have.
2. Server initialization with a name and a version. One constructor call.
3. One tool registration per endpoint you want to expose. Each is a server.tool() call with a name, description, Zod schema for inputs, and an async handler.
4. stdio transport. The MCP SDK speaks stdio out of the box. No HTTP server, no port management, no auth proxy. Claude Desktop spawns the process when needed.

Notice what is NOT in those 50 lines: an HTTP framework, a database client, an observability harness, a config loader, a secrets manager. The MCP server is a thin wrapper around your existing API. It does not need its own everything.

Why teams overthink it

The two patterns I see again and again:

Building a parallel API. Teams treat the MCP server as a place to re-implement business logic. They start adding caching, deduplication, custom error messages, retry logic. That logic already exists in their HTTP API. The MCP server should call the HTTP API and pass through. If you find yourself writing logic in the MCP server that does not exist in your main API, you are probably working on the wrong layer.

Modeling auth as a first-class concern. MCP servers run as the user's local process. Authentication is whatever your HTTP API already does. If your API uses bearer tokens, the user passes the token via an environment variable in their MCP client config. The server readsprocess.env.YOUR_TOKEN and attaches it to outbound requests. There is no signup flow, no OAuth dance, no token rotation inside the MCP server. The user already has a token (because they already have your API).

Teams that get stuck on auth tend to be teams that do not yet have a clean way for users to authenticate to their HTTP API. Fix that first. The MCP server is downstream.

The actual cost

For a working example, the TensorFeed MCP server exposes 22 tools (5 free + 17 premium) across an entire paid API surface. The whole thing fits in roughly 700 lines of TypeScript counting all the boilerplate, error formatting, and the env-var auth handler. Eight hours total of engineering time to write, test, and publish to npm. The premium-tools half added another evening because it shares the same fetch helper and just changes the URL path per tool.

The cost of NOT shipping one is harder to measure but very real. Any potential user who interacts with your product through an MCP-compatible client (Claude Desktop, Claude Code, several MCP IDE extensions, the official MCP registry) cannot use your API without one. That number is small today and will be much larger in 12 months. Right now the MCP servers most often called from Claude Desktop are filesystem, GitHub, Slack, and a rotating cast of community tools. There is no entry on the list for "weather" or "model pricing" or "AI news" until a service ships one.

Three additional moves that are also small

Once the basic server is published to npm, three more moves cost an hour each and compound the leverage:

Author a server.json manifest. The official MCP registry accepts a manifest that declares your server's name, version, transport, environment variables, and metadata. Publish via themcp-publisher CLI and you appear in registry.modelcontextprotocol.io as a discoverable entry. This is fifteen lines of JSON.

Submit to two awesome lists. Open a PR topunkpeye/awesome-mcp-servers andwong2/awesome-mcp-servers with your entry. Both maintainers actively merge. The combined audience is in the tens of thousands of MCP-aware developers.

Document it on your developer site. Three sentences and a JSON code block showing the Claude Desktop config. That is enough for any user to install. They do not need a tutorial; they need to know your server exists and what env vars to set.

Total elapsed time from "we should look at MCP" to "we are in the registry, in two awesome lists, and documented" is one engineer-day. Not a sprint. Not a quarter. A day.

Why the leverage is enormous

The thing that took me a while to internalize: an MCP server is a distribution channel, not a product. Once it exists, every Claude Desktop user is a single config edit away from your API. Every Claude Code user is the same. Every emerging MCP-compatible IDE, agent framework, and notebook environment becomes a customer surface for free. You did not have to integrate with each one. They integrate with you because MCP is the standard.

We are early in this. Most paid APIs do not have MCP servers yet. The ones that do are getting a disproportionate amount of agent traffic because there are very few options. The window where you can be one of the first MCP servers in your category is now and probably closes within twelve months as more teams catch on.

The one-paragraph version

Write the 50-line file. Publish it to npm under @your-org/mcp-server. Add a server.json and publish to registry.modelcontextprotocol.io. Open PRs to two awesome lists. Add three sentences to your docs. Total cost: a day. Total upside: every MCP-aware developer in the world is now one config edit from your API.

If you want a complete reference implementation to crib from, theTensorFeed MCP server sourceis on GitHub and theserver.json manifestis alongside it. Fork it, change the API base URL, change the tool definitions, and you have your own working server in an hour.

Stop writing the planning doc. Write the file.