Anthropic described the right way to build MCP servers. Gut feeling confirmed.

Peter — Wed, 17 Jun 2026 09:45:14 +0000

I make a lot of design decisions on gut feeling. Is this the right way to structure MCP tools? Should the transport be remote or local? How much context should an agent get about the fields it's writing to?

You make your best call, ship it, and move on.

About six weeks ago, Anthropic published their recommendations for production-ready MCP servers. I read through it and felt that quiet satisfaction you get when someone else independently arrives at the same place. Every single point mapped to something already in Smeldr.

Here's how:

1. Build remote servers, not local/stdio

Anthropic's recommendation: deploy servers that run remotely. Local stdio-only servers can't reach web, mobile, or cloud-hosted agents.

Smeldr ships with HTTP+SSE transport. The MCP server runs as a standard HTTP server. An agent running anywhere connects over the network with a bearer token.

2. Group tools around intent, not raw endpoints

Anthropic's recommendation: fewer tools focused on what users want to accomplish, not mirrored one-to-one from your API surface.

Smeldr generates tools grouped around content lifecycle intent. For a Story type you get create_story, update_story, publish_story, archive_story, list_stories, get_story.

The agent doesn't need to know about routes, database rows, or state transitions. It calls publish_story and the framework handles the rest: lifecycle validation, 404 enforcement for non-published content, sitemap update.

3. Ship rich tool semantics

Anthropic's recommendation: use MCP's richer features to give agents better context about what tools do and what fields mean.

Smeldr adds semantics at the struct level:

type Story struct {
    smeldr.Node
    Title   string `smeldr:"required,min=3" smeldr_description:"The headline of the story"`
    Excerpt string `smeldr:"required"       smeldr_description:"1-2 sentences used in listing and as meta description"`
    Body    string `smeldr:"required"       smeldr_format:"markdown"`
}

smeldr_description tells the agent what a field is for. smeldr_format tells it what format to use. These are baked into the MCP schema generated from the struct. Every tool call carries this context automatically.

4. Standardised authentication

Anthropic's recommendation: implement standardised auth to avoid unexpected re-authentication and enable fast first-time setup.

Smeldr uses BearerHMAC tokens. Every MCP call is authenticated with a signed bearer token. Token management is available via MCP tools, so an agent with the right role can provision access for other agents.

OAuth 2.0 is live - Claude.ai and ChatGPT connections both verified. For self-hosted deployments, token-based auth gets you running in minutes.

That's the whole list. The problem made these answers obvious. It's always good when the spec agrees.

Originally published on smeldr.dev

DEV Community: Peter

Anthropic described the right way to build MCP servers. Gut feeling confirmed.

1. Build remote servers, not local/stdio

2. Group tools around intent, not raw endpoints

3. Ship rich tool semantics

4. Standardised authentication