Six weeks from 'I should publish an MCP server' to 'the server is live, registered, scored 100/100 on Smithery, and listed in three directories.' The log is week-by-week, with the actual command lines and the actual mistakes.

MCP for Engineers Who Hate Marketing: A 6-Week Build Log

9 min read
authoritymcp

Six weeks from “I should publish an MCP server” to “the server is live at mcp.sovgrid.org/self-hosted-ai, registered in the official MCP registry, scored 100/100 on Smithery, listed in Glama as both connector and server, and merged into awesome-mcp.” This is the log with the actual command lines and the actual mistakes.

The reason this is a 6-week timeline rather than a 6-hour one: writing the code is the fast part. The slow parts are the directory review queues (Glama took a week, awesome-mcp took two), the feedback cycles, and the integration testing in production agent contexts. One operator working nights and weekends can close all of these loops in 6 weeks because none of the steps require external dependencies beyond the reviewer queues.

Quick Take

  • Week 1: write the four tools. Pick four real workflow needs, write the tool implementations, expose them via FastMCP.
  • Week 2: deploy publicly. Put the server behind a real domain, behind a real reverse proxy, with real HTTPS. Test from external clients.
  • Week 3: ship the documentation. A README in the repo that explains what the tools do, when to use them, and the failure modes.
  • Week 4: register in directories. Submit to the official MCP registry, Smithery, Glama, awesome-mcp. Each has different metadata requirements.
  • Week 5: respond to feedback. Each directory’s reviewers find issues; fix them; resubmit.
  • Week 6: integrate with a real agent. Test the live MCP from OpenWebUI, Claude Code, opencode. Confirm the tools actually work in production agent contexts.

Week 1: write the four tools

The first decision is which tools to write. The temptation is to write a generic “search anything” tool; the right approach is to pick four specific workflows your agents actually need.

For sovgrid, the four tools were:

The four tools cover the actual use cases the agents wanted: “find me an article that addresses this question” (search_blog + get_article), “what topics does this site cover” (list_tags), and the one specialty tool that exposes domain expertise (diagnose_sglang). Four is a manageable number; ten is a confusing one.

Why MCP over a custom HTTP API: the protocol is client-agnostic. Once the server exists, Claude Code, OpenWebUI, opencode, and any future agent client can connect without writing custom integration code. A bespoke HTTP API requires every consumer to understand its schema and write a client; MCP clients already know how to call tools/list and tools/call. That is the concrete value: one implementation, many consumers, zero per-client glue code.

The implementation language is Python with FastMCP. The library handles the MCP protocol boilerplate; the operator writes the tool logic.

from fastmcp import FastMCP

mcp = FastMCP("sovgrid")

@mcp.tool()
def search_blog(query: str, limit: int = 10) -> list[dict]:
    """Search the sovgrid corpus for articles matching the query."""
    results = vector_search.query(query, limit=limit)
    return [{"slug": r.slug, "title": r.title, "score": r.score} for r in results]

if __name__ == "__main__":
    mcp.run()

The first version runs locally on stdio. The next step is to make it publicly reachable.

Week 2: deploy publicly

The local-only stdio version is fine for development. Production needs HTTPS, a domain, and a reverse proxy.

The architecture: the MCP server runs as a systemd service on the Spark, behind a Cloudflare Tunnel that terminates at the Floki VPS. Caddy on Floki routes mcp.sovgrid.org to the tunnel endpoint.

The Caddy entry:

mcp.sovgrid.org {
    reverse_proxy 127.0.0.1:8888
}

The Cloudflare Tunnel ingress entry on the Spark:

- hostname: mcp.sovgrid.org
  service: http://127.0.0.1:8888

The systemd unit:

[Service]
ExecStart=/usr/local/bin/python /opt/sovgrid-mcp/server.py --port 8888
Restart=on-failure
Environment=VLLM_ENDPOINT=http://localhost:8000

By the end of week 2 (mid-April 2026), the server is reachable from external networks. The test is curl https://mcp.sovgrid.org/health. (For the broader Caddy + Tunnel pattern, see Caddy + Cloudflare Tunnel: The Reliability Pattern.)

One caveat on the Cloudflare Tunnel approach: the Tunnel adds a dependency on Cloudflare’s network. If Cloudflare has an incident, the MCP server is unreachable even if the Spark is healthy. For a personal productivity server this is an acceptable trade-off; for a production service with SLA commitments it is not.

Week 3: ship the documentation

The MCP protocol has a built-in capability-discovery endpoint (tools/list), but the documentation that humans read needs to be more than that.

The README in the GitHub repository covers:

The example inputs and outputs are the most important section. An agent integrator who is choosing between MCP servers will read these to decide if the server fits their use case. Vague descriptions get the server skipped.

For sovgrid, the README is in the public repo and is roughly 600 lines. The investment is half a day; the dividend is every directory listing that displays a clean README excerpt.

Week 4: register in directories

Four directories, four metadata formats.

Official MCP registry. The canonical registry uses a DNS-based authentication mechanism: the server’s DNS includes a TXT record with an ed25519 public key, and the registry verifies ownership by checking that the submitted server signs a challenge with the matching private key. The sovgrid MCP went live as org.sovgrid/self-hosted-ai on 2026-05-05. The registration is a few hours of work once you have the ed25519 keypair generated.

Smithery. Smithery scores MCP servers from 0 to 100 on documentation quality, schema adherence, and operational signals. The sovgrid MCP scores 100/100 as of May 2026 (see Setup: MCP Listing Smithery 100 for the optimization details). Smithery’s metadata is YAML in a specific format; the conventions are documented and the validator catches most mistakes.

Why the Smithery score matters: a 100/100 score means the server’s metadata is complete and the tooling can auto-generate correct connection instructions for consumers. That is why directory placement and discoverability improve with a higher score; the score is a metadata quality proxy, not a capability audit. Where it does not matter: the score says nothing about whether the tools return useful results, whether the server stays online, or whether the underlying data is current. A 100/100 server with bad tool implementations is still a bad server.

Glama. Glama lists both connectors (clients that consume MCP) and servers (providers of MCP tools). The sovgrid MCP is listed as both, currently at v0.1.1. Glama’s submission process is a web form; the metadata is simpler than Smithery’s.

awesome-mcp. A GitHub-style awesome list maintained as a curated repository. Submit via PR with a one-line entry in the appropriate section. The sovgrid entry merged as PR #5645.

Each directory has its own review timeline. The official registry was same-day. Smithery took roughly 48 hours. Glama took a week. awesome-mcp took two weeks for the PR review.

Week 5: respond to feedback

The directory reviewers find things. Mostly small; sometimes substantive.

Smithery flagged that the original tool schemas had inconsistent parameter naming (query in one tool, q in another). I unified to query. The schema validator now passes.

Glama’s reviewer asked for a clearer “what does this server uniquely do” statement. The original description was generic; I rewrote it to emphasize “self-hosted DGX Spark expertise” specifically.

The awesome-mcp PR reviewer asked for the category to be moved from “search” to “specialized-knowledge.” Done.

The feedback cycle is real and pays off. Each directory’s review process surfaces a real polish item. The work after week 5 is the work that produces 100/100 scores rather than 90/100 scores.

In week 5 (mid- to late April 2026), all three feedback items were resolved in a single afternoon. The changes were small in code terms; the value was in having the external reviewers flag what I had normalized past. In practice: the parameter naming inconsistency (query vs. q) had been there since week 1 and I had not noticed it because I wrote both tools myself.

Week 6: integrate with a real agent

The final step: confirm the MCP actually works in production agent contexts.

Test 1: connect from Claude Code via its MCP configuration. The agent should be able to call search_blog and get useful results. (It did, after one config tweak.)

Test 2: connect from OpenWebUI’s MCP-O integration. The MCP-O proxy ran on Floki and exposed the sovgrid MCP tools to the Sovereign Qwen custom model in OpenWebUI. Confirmed working with both list_tags and get_article as native function calls.

Test 3: connect from opencode running against a local Qwen 3.6 endpoint. The integration worked after fixing one tool-call schema issue specific to Qwen’s tokenizer.

By the end of week 6 (early May 2026), the MCP is integrated with three real agent clients, scoring well in four directories, and serving real queries.

What the registry listing does not buy you

A directory listing is discoverability infrastructure, not a guarantee of usage. The listing gets the server in front of people searching for MCP tools; it does not drive queries to the tools unless those people have a real use case that matches what the tools do.

In practice, the sovereign-ai MCP had zero external agent queries in the first month after listing. The actual usage came from my own agents (Claude Code, OpenWebUI) which I configured manually. That is expected: a niche server serving a niche use case (DGX Spark + sovgrid corpus) will not have broad organic adoption. The listing is still worth doing because it makes the server findable for the one person who needs exactly this.

A second limitation worth naming: the official MCP registry, Smithery, and Glama are all young directories (as of mid-2026). Their long-term maintenance status is not proven. Building an audience via the registry listing rather than via your own RSS or Nostr is a structural dependency on their continued operation.

What I would do differently

Pick fewer tools to start. Four was right for me; many operators publish ten and dilute the focus. Two well-implemented tools beat ten half-implemented ones.

Write the documentation before the directory submissions. Directories ask for README excerpts; if the README is incomplete, the directory listing looks incomplete. In my case the README was mostly done before submission, which is why the week 4 submissions went smoothly compared to operators who write it in parallel with the review queue.

Reserve a week for feedback. The directories take longer than expected to review. Plan for the calendar week of slack, not just the work hours.

Where this fits

For the broader MCP context, see Setup: Sovereign MCP Setup and Setup: MCP Listing Smithery 100. For the strategic argument, see Strategy: MCP Registry Distribution.

Follow the operational follow-up

The follow-up article at the three-month mark covers what the operational profile of a live MCP looks like: query volumes, failure modes, the maintenance work. Follow on Nostr (cipherfox@sovgrid.org) or subscribe to the RSS feed at /rss.xml to catch it when it lands.