Design your MCP server surface before you write code

An MCP server exposes some combination of resources (read), tools (write), and prompts (templates). Before you start building, write down exactly which of each you need and the audience — internal, partner, or public. Scope dictates auth, rate limits, and observability, so it has to be decided up front.

If your audience is Claude Desktop power users inside your company, stdio transport is fine. If it's a team or partner, you need HTTP/SSE, an auth gateway (OAuth, SSO, or scoped tokens), and deployment — Lambda, Azure Functions, or Cloudflare Workers all work. Don't build one and retrofit the other later.

Version contracts explicitly. MCP is moving fast; clients break when the server changes. Decide up front whether you're pinning a spec version, what deprecation windows look like, and how you'll communicate breaking changes. Treat the server surface the way you'd treat a public API — because that's effectively what it is.

Trace every tool call. Input, scope, output, tokens, latency, cost. The resulting dataset is how you spot misbehaving clients, plan capacity, and attribute usage back to teams or products.