This page points you at official first-server guidance and summarizes the non-negotiables from those docs. For copy-paste full code, use the official tutorial and sample repos — they are maintained with the SDKs.
Start here (official)
- Build an MCP server — weather server (
get_alerts,get_forecast) for Python, TypeScript, Java, Kotlin, C#, Ruby, and more - SDKs — official language SDKs and tiering
- Understanding MCP servers — tools / resources / prompts
- MCP Inspector — test and debug servers
Complete sample code (linked from the official tutorial):
- Python: quickstart-resources/weather-server-python
- TypeScript: quickstart-resources/weather-server-typescript
What you will build
Per the official quickstart narrative:
- An MCP server that exposes tools
- Connection from a host (Claude for Desktop in the tutorial)
- Usually stdio transport for the first local run
Core capabilities servers can provide (official tutorial):
- Resources — file-like data clients can read
- Tools — functions the LLM can call (with user approval patterns in hosts)
- Prompts — pre-written templates
The weather tutorial focuses on tools.
Official SDKs (check live tiers)
From SDKs (verify on that page — tiers can change):
| SDK | Tier (as documented on the SDKs page) |
|---|---|
| TypeScript, Python, C#, Go | Tier 1 |
| Java, Rust | Tier 2 |
| Swift, Ruby, PHP, Kotlin | Tier 3 |
Repos: SDK tiering.
Typical packages (from the official build guide)
- Python:
mcp[cli]viauv add "mcp[cli]" httpx— usesFastMCPin the weather example; Python 3.10+, MCP Python SDK 1.2.0+ per that page - TypeScript:
@modelcontextprotocol/sdk+zod—McpServer+StdioServerTransport; Node 16+ per that page
Always follow the version pins in the current tutorial.
Critical stdio rule (official)
From Build an MCP server:
| Transport | Logging rule |
|---|---|
| STDIO | Never write application logs to stdout — it corrupts JSON-RPC |
| HTTP-based | Standard output logging is fine for HTTP responses |
Examples from the docs:
- TypeScript: use
console.error, notconsole.log - Python:
print(..., file=sys.stderr)or logging to stderr
This matches the stdio transport specification: only valid MCP messages on stdout.
Local host configuration (Claude for Desktop)
The official tutorial configures Claude for Desktop via mcpServers in:
- macOS:
~/Library/Application Support/Claude/claude_desktop_config.json - Windows:
%APPDATA%\Claude\claude_desktop_config.json
Shape (stdio): command + args launching your server process (e.g. uv run weather.py or node …/build/index.js). Use absolute paths. Restart Claude for Desktop after edits.
Official client connection guides:
Verification checklist (protocol-level)
Before calling a server “done”:
- Lifecycle initialize succeeds (lifecycle)
tools/listreturns your tools (tools spec)tools/callsucceeds for a happy path- Prefer the MCP Inspector for structured debugging
From first server to production
Official local tutorials stop at desktop/stdio. For a shared remote URL:
- Prefer Streamable HTTP for new remote servers (transports 2025-11-25)
- Package as Git / image / package for your host
- On MCPLambda, add
mcplambda.yamlfor Git builds and deploy via Getting Started
See package for production and production-ready with mcplambda.yaml.
Worked scenario: First tool, then first remote
You follow the official weather-server tutorial with stdio and Claude Desktop. get_alerts works. Next you try to “share it with the team” by emailing your absolute path config—chaos.
You treat the tutorial as phase one. Phase two: env-based config, Streamable HTTP or a managed host, auth, and a real smoke test. You keep using official SDKs and never console.log on stdio.
The win is not a clever framework; it is a boring, tested tool that hosts can call.
Checklist for this topic
- Complete official quickstart for your language
- Verify tools/list and tools/call locally
- Respect stdio logging rules
- Use official SDKs from the SDKs page
- Only then package for remote/shared use
- Add auth before sharing a URL
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Stdout breaks server | console.log/print | stderr logging |
| Cannot share with team | stdio-only | Remote transport or managed host |
| Wrong SDK version | Copy-paste from old blogs | Follow current official tutorial |
| Tools not showing | Host config path wrong | Absolute paths; restart host |
Related guides
Transports · Package for production · Official build guide
In practice: definition of “done” for v0
- Official tutorial path works on your machine
- tools/list shows your tool
- One host can invoke it
- README lists env vars
- No secrets in repo
- You know the next step to remote/share
v0 is learning. Production is a later checklist.
After the tutorial: three good next tools
- A pure function tool (calculator/time) — proves plumbing
- A read-only HTTP GET wrapper — proves secrets/env
- A write tool with confirmation — proves safety UX
Do not start with “automate the entire company.”
Takeaways
For Build Your First MCP Server (Official Quickstart Path), remember three things:
- Be specific to this problem — the worked scenario “First tool, then first remote” is the failure mode you should design against, not a generic outage narrative.
- Ship one boring tool first — prove
tools/listand onetools/callbefore packaging or hosting. - Follow the official SDK quickstart in your language, then package for remote with a pinned artifact.
If you only remember one habit: do not mark a hello-world server done until a host other than your terminal can list and call the tool.
Sources
- Build an MCP server
- SDKs
- Transports — 2025-11-25
- Tools — 2025-11-25
- MCP Inspector
- Sample repos under modelcontextprotocol/quickstart-resources
Next steps
Complete the official weather tutorial in your language, then package and deploy when you need a remote endpoint.
