How I Built and Published an MCP Server in 14 Hours

The Problem I Wanted to Solve

I had been building OTTASIA - a streaming-discovery web product for Asian markets - and I kept noticing the same pattern when I tested it with my AI assistants. If I asked Claude "where can I watch Pulang Araw in the Philippines?", I would either get a confident-sounding wrong answer or a polite refusal. The model genuinely cannot know this. Streaming availability changes weekly, varies by country, and is held in 200+ separate provider catalogs that no foundation model is trained on.

This is exactly the gap MCP - Model Context Protocol - was built for. Instead of trying to bake live, frequently-changing data into the model, you expose it as a server the model can call when it needs that data. The model says "I have an MCP tool called where_to_watch, let me use it." The tool runs, returns structured data, and the model uses that to answer.

I had been reading other people's MCP servers all month - Anthropic's Slack and GitHub connectors, community ones for Notion and Linear, a few specialty ones for finance APIs. The protocol is genuinely simple. I wanted to ship my own.

The Constraint: One Saturday

I had been running a 60-day GTM sprint for OTTASIA. Every day in May 2026 was already booked: scrapers, country expansions, mobile app prep, SEO audit. The only slot I could carve out for an MCP server was Day 9 - Saturday, May 23. One day. About 14 hours of focused work between morning coffee and shutting down at midnight.

This is the kind of constraint that actually clarifies thinking. With unlimited time you can endlessly debate what tools to build. With 14 hours and a public commitment to ship that day, the question changes from "what could this do?" to "what is the smallest version of this that would still be useful?"

Choosing the Three Tools

I started by writing down every streaming question I had personally asked an AI assistant in the past three months. There were 40 of them. They fell into three buckets:

• Bucket 1: "Where can I watch X?" - by far the most common, maybe 60% of my queries.
• Bucket 2: "What is new on [provider] this week?" - second most common.
• Bucket 3: "Search for shows like X" - a fallback when I was not sure of the exact title.

Those three buckets became the three tools. I deliberately resisted adding a fourth or fifth tool, even though I could think of many. Each additional tool meant more API endpoints to maintain, more test cases, more documentation, more chances of bugs. Three good tools beat ten mediocre ones - especially when you have 14 hours.

Tool 1: where_to_watch(title, country)

The most-used tool. Takes a title name and a country code. Returns the OTT providers that stream that title in that country, grouped by stream / free-with-ads / rent / buy. Uses the same backend the OTTASIA web product uses, so there is one canonical source of truth.

Tool 2: whats_new_on(provider, country, limit)

For queries like "what is new on JioHotstar this week." Takes a provider, a country, and an optional limit. Returns recently added titles for that combination. This is the tool I expected to be the second most useful but turned out to be more popular than I thought - probably because users have a habit of asking "what should I watch" and AI assistants then narrow it down with this.

Tool 3: search_titles(q, country, limit)

The fallback. When the user's query is ambiguous ("joker", "the office"), this returns matching titles with country-aware return links. The model can then either pick the most likely match and call where_to_watch on it, or present a short list back to the user.

The Technical Stack

I used the official Model Context Protocol SDK in TypeScript. The MCP team has done a genuinely good job with the SDK - declarative schema for each tool, validation built in, and the transport layer abstracted so I did not have to think about stdio versus HTTP until later.

The full stack ended up being:

• Runtime: Node.js 20+, distributed via npx so users do not have to install anything.
• Language: TypeScript, compiled to plain JS for distribution.
• SDK: @modelcontextprotocol/sdk for the protocol handling.
• Data backend: The existing OTTASIA APIs (Next.js routes on Netlify) - no separate infrastructure, no data drift.
• Transport: Started with stdio (the default for Claude Desktop). Added Streamable HTTP at ottasia.com/api/mcp/sse in v0.2.0 for browser-based clients like mcp.so playground.

How the Code Is Structured

Each tool is its own file. The schema and the implementation live together so it is impossible to update one without the other. A minimal MCP tool looks something like this:

// tools/where_to_watch.ts
export const whereToWatchTool = {
  name: 'where_to_watch',
  description: 'Returns OTT providers streaming a specific title in a specific country.',
  inputSchema: {
    type: 'object',
    properties: {
      title: { type: 'string', description: 'The title name' },
      country: { type: 'string', description: 'ISO 3166-1 alpha-2 country code' }
    },
    required: ['title', 'country']
  },
  handler: async ({ title, country }) => {
    const data = await fetchProviders(title, country);
    return { content: [{ type: 'text', text: formatResponse(data) }] };
  }
};

The protocol is dramatically simpler than what I expected from reading the spec for the first time. There is a small surface area: register the tool with name, description, schema. Write a handler. Done. The SDK takes care of the wire format, validation, and error handling.

The hardest part was deciding what to return - not just the raw data, but a format that makes it easy for the model to construct a good answer. I spent maybe two hours iterating on the response format. The lesson there: optimise for how the answer reads to a human, not how clean the JSON looks. Models are surprisingly good at parsing slightly messy text and surprisingly bad at constructing nice prose from sterile JSON.

Publishing to npm

This was the part I had been most worried about. I had never published an npm package before. It turned out to take about 20 minutes.

• Created an npm account and verified my email.
• Set up the package.json with the right "bin" field so the package would be runnable via npx.
• Wrote a clean README with installation instructions and a config snippet for Claude Desktop.
• Ran npm publish --access public. Watched the upload.
• Two minutes later it was live at npmjs.com/package/@ottasia/mcp-server.

That moment - looking at my own package on the npm registry - was genuinely emotional. The threshold for getting code into the npm ecosystem is now low enough that any focused weekend can produce a published, installable package. The mental shift that goes with that is the bigger story.

Getting Listed in 6 Directories

Publishing to npm gets you the package. Discoverability is a separate game. There are several "MCP discovery surfaces" that the AI assistant ecosystem uses, and I wanted to be in all the major ones on launch day.

Each of these took 10 to 30 minutes. By the end of Day 9 the package was listed in five of them, with the awesome-mcp-servers PR open and merged a few days later. The lesson: do the directory work all at once. Submitting them in one focused block is much faster than coming back to it later, because the same metadata (description, README link, screenshot) is reused everywhere.

Launch Day: Twitter, Reddit, and 450 Downloads

The package was published around 6 PM on Saturday. I wrote a short Twitter thread explaining what it did and why - kept it under 5 tweets, no hype, just the facts. Cross-posted a slightly longer version to r/ClaudeAI and r/MachineLearning, both of which I had been a regular reader of for months.

By midnight that night the package had 450 downloads. Most of them - based on the timestamps - came from the Reddit posts. The Twitter thread drove maybe 80. The official MCP Registry listing drove a steady trickle that has not stopped since.

I had not been expecting that level of day-one interest. The takeaway: there is genuine pull for new MCP servers right now. People who use Claude every day are actively looking for new capabilities. If you build something that fills a real gap and you announce it where those people hang out, the audience is already there.

515 Downloads in 5 Days: What I Learned

Steady 10 to 20 downloads per day since the launch day spike. No additional marketing. Most of the post-launch downloads come from the directories - particularly the official MCP Registry and mcp.so, both of which auto-syndicate to other tools (PulseMCP, mcp-get).

What surprised me

1. The "long tail" is real. Day-one downloads are nice for ego. But the steady organic 10-20/day since is what tells me the package is actually being used. Those downloads come from people who searched a directory, not from people who saw my tweet.

2. The MCP Registry punches above its weight. Being in the official registry signals quality to other directories. Several of them auto-pull from it. It is the single highest-leverage listing.

3. Zero support tickets so far. I had been bracing for installation issues, edge cases, weird country-code bugs. None of it. Either nobody is testing it carefully (unlikely - 515 downloads), or the SDK is good enough that obvious bugs are caught before they ship. Probably both.

What I would do differently

1. Ship the HTTP transport on Day 1. I added Streamable HTTP in v0.2.0 a few days later. If I had built both transports from the start, the package would have worked in browser-based MCP clients (like mcp.so playground) on launch day, which would have driven more discovery.

2. Write the launch tweet thread first. I wrote it after the package was published. If I had drafted it the night before, I could have iterated on the framing - which is the part that determines whether anyone shares it.

3. Cut the README in half. I wrote a long README and it works, but most people skim. The Claude Desktop config snippet should have been the first thing visible, not the 5th section.

Practical Advice If You Want to Build One

1. Pick a real problem you personally have. Three of the most successful MCP servers I have seen all came from "I needed this for myself" not "I think this would be useful for others." Your motivation has to survive the boring middle hours of development. Personal pain is the most durable motivation.

2. Three tools maximum. If you cannot describe what you are building in three tools, the scope is too big. You are building a v1, not a complete platform. Add tools later if the v1 finds real users.

3. Use the official SDK. Do not try to implement the protocol yourself. The SDK handles transport, validation, error handling, and updates. You focus on your tools.

4. Test in Claude Desktop before publishing. The dev experience for MCP is genuinely good once it works. The dev experience when something is misconfigured is rough. Get it working locally first.

5. Write good tool descriptions. The descriptions are what the model uses to decide when to call your tool. Bad descriptions mean your tool gets ignored even when it would be helpful. Spend real time on this.

6. Do all the directory submissions on launch day. Batch the discovery work. The metadata is reusable across submissions.

7. Announce in 2-3 places, not 10. Pick the communities where people who use the relevant AI assistant actually hang out. For Claude, that is r/ClaudeAI plus your existing Twitter audience. For broader AI, r/LocalLLaMA and r/MachineLearning.

Resources to Get You Started

• Official Model Context Protocol documentation - the canonical spec and SDK docs.
• modelcontextprotocol/servers - Anthropic's own example MCP servers, great reference templates.
• awesome-mcp-servers - the de-facto curated list. Browse here to see what already exists and where the gaps are.
• mcp.so - directory with a built-in playground for testing servers.
• @ottasia/mcp-server - the server from this post, available as a reference for the patterns described above.

The Bigger Point

The Model Context Protocol is what turns a chat assistant into a platform. Before MCP, the only way to give Claude a new capability was to wait for Anthropic to build a feature for it. After MCP, anyone with a Saturday and a TypeScript file can publish a capability and have it show up in every Claude Desktop instance on the planet.

That is a meaningful shift in who gets to extend AI assistants. It is not just FAANG-scale engineering teams anymore. It is increasingly individual developers and small teams who see a specific gap and decide to fill it. The ecosystem rewards builders who ship.

If you have a niche data source, an internal tool, a specific workflow that you wish Claude could touch - the path is well-documented and the bar to entry is low. The hardest part is actually starting. Once you start, 14 hours is a realistic timeline.