Starting from scratch does not mean rebuilding the protocol from scratch.

Choose the official MCP starter closest to your existing stack, build one useful surface, and put mcp-doctor beside it before the server grows.

Language adoption snapshot Enjoyable Work

Language adoption across official MCP SDK tiers

  • Python 54.8% · Tier 1
  • TypeScript 48.8% · Tier 1
  • C# 29.9% · Tier 1
  • Go 17.4% · Tier 1
  • Rust 14.5% · Tier 1
  • Java 29.6% · Tier 2
  • Ruby 6.9% · Tier 2
  • PHP 19.1% · Tier 3
  • Kotlin 11.5% · Tier 3
  • Swift 5.7% · Tier 3

Percentages show the share of professional developers in the 2025 Stack Overflow survey who used each language extensively in the past year. All bars use one scale normalized to Python, and languages are ranked within their official SDK tier. This is general language use—not MCP SDK installs, SDK quality, or project fit. The sample overrepresents highly engaged Stack Overflow users.

2025 Stack Overflow survey Survey methodology Official MCP SDK tiers

Start with the official path closest to your stack

The current MCP documentation already offers guided server examples and official SDKs. Reuse that work instead of hand-writing the wire protocol or copying an old community snippet.

Guided server tutorial Follow a complete starter in one of eight languages The official build guide currently covers Python, TypeScript, Java, Kotlin, C#, Ruby, Rust, and Go. Official SDK directory Check every supported language and its current tier The SDK directory adds Swift and PHP, and links to the installation steps, documentation, and examples owned by each SDK.

Choose the path with the least new machinery

The best starter is usually the one your team can understand, run, and maintain without introducing another runtime just for MCP.

  • Match the stack. Stay with the language, package manager, deployment model, and test tools your service already uses.
  • Start with one real job. Expose one tool, resource, or prompt tied to a user task before expanding the catalog.
  • Name the boundary. Decide whether the first server is local or remote, what data it can reach, and which actions require explicit authority.

The protocol contract nearly doubled in 21 months

Across five official MCP revisions, the top-level reusable definitions in the versioned JSON Schema rose from 79 to 155. Pinning a revision keeps the contract you build and test explicit.

This measures schema structure—not implementation difficulty, normative requirements, compatibility, or protocol quality.

View source data and counting method
The protocol contract nearly doubled in 21 months
MCP revisionTop-level $defs
2024-11-0579
2025-03-2683
2025-06-1891
2025-11-25145
2026-07-28155
Official MCP versioned JSON schemas Top-level $defs were counted at specification commit 57ac4a2, reviewed August 24, 2026.

Put mcp-doctor in the loop while the surface is small

Do not wait for a large server and a release deadline to learn what an MCP client will discover. Add a separate check as soon as the starter runs.

  1. Inspect locally

    mcp-doctor v0.4.0 inspect starts the selected local command or contacts the selected remote endpoint, then checks discovery, definitions, and schemas without invoking a listed tool.

  2. Fix, then inspect again

    Keep the feedback loop beside the code. A person or coding agent can make the change, while mcp-doctor gives the next pass a separate, bounded result.

  3. Repeat the pinned check in CI

    Use the same reviewed target and protocol revision as a merge checkpoint so the check does not depend on memory or the original builder’s context.

Keep building one verified edge at a time

Once the starter and its first advertised surface are stable, expand only where the next user task requires it.

  • Keep normal unit and integration tests for business meaning; a protocol diagnostic does not replace them.
  • Add reviewed active checks only when you control the target, input, authority, and possible side effects.
  • Add tools, resources, prompts, remote transport, and authorization deliberately, rerunning the local and CI checks as the surface changes.

The starter gets you moving. The repeatable verification loop keeps “it runs” from becoming the only evidence you have.

The next useful guide depends on whether you are still deciding to offer MCP or already preparing an AI-built server for launch.

See why some users want their chosen AI agent to reach a product through MCP—and where that demand signal stops. See how mcp-doctor fits between an AI-built server, local development, CI, and a reviewed launch.
After the starter runs

Add the independent check

Review the mcp-doctor inspection and testing boundary, then choose the least-active diagnostic that answers your next question.

Read the inspection and testing guide

Sources and boundaries

Current official MCP documentation supports the starter and SDK-tier summary. Released mcp-doctor v0.4.0 documentation supports only the product behaviour attributed to that version.

SDK tiers, guides, and release lines can change. Recheck the official sources before implementation. Structural diagnostics do not establish semantic truth, security, compliance, production readiness, or model success.